Drop `LegacySpecifier` and `LegacyVersion` #407

pradyunsg · 2021-02-28T10:03:13Z

Follow up to #342.
Closes #530

Let's do this. :)

jdufresne · 2021-02-28T15:06:29Z

WDYT about dropping _BaseVersion in favor of just a Version class (merging the classes really)? Likewise, how about dropping BaseSpecifier?

jdufresne · 2021-02-28T15:11:23Z

This is more a question, should canonicalize_version now raise an InvalidVersion exception rather than returning the legacy version string?

packaging/utils.py
47               # Legacy versions cannot be normalized

I believe the docs need to be adjusted (I grepped for "legacy"):

docs/specifiers.rst
57       (:class:`Specifier`) or as a legacy, setuptools style specifier
58       (deprecated :class:`LegacySpecifier`). You may combine
94           :class:`Version`, or a deprecated :class:`LegacyVersion` object, is
110          deprecated :class:`LegacySpecifier`) instances in this specifier set.
115          and deprecated :class:`~.LegacyVersion` instances and will then filter
172  .. class:: LegacySpecifier(specifier, prereleases=None)
178      This class abstracts the handling of a single legacy, setuptools style

docs/version.rst
54       will parse it as a deprecated :class:`LegacyVersion`.
141  .. class:: LegacyVersion(version)
160          :class:`LegacyVersion` instances are always ordered lower than :class:`Version` instances.
162          >>> from packaging.version import Version, LegacyVersion
164          >>> v2 = LegacyVersion("1.0")
167          >>> v3 = LegacyVersion("1.3")
172          other versions that are not (:class:`LegacyVersion`). Examples include versions with `Pre-release spelling`_ and
198          <LegacyVersion('0.9.8t')>
207          :class:`LegacyVersion`. This will always be the entire version string.
212          :class:`LegacyVersion` instance. This will always be the entire version
219          :class:`LegacyVersion` instances always compare less than
226          primarily to allow a :class:`LegacyVersion` to be used as a stand in
233          :class:`LegacyVersion` to be used as a stand in for a :class:`Version`.
239          :class:`LegacyVersion` to be used as a stand in for a :class:`Version`.
243          A boolean value indicating whether this :class:`LegacyVersion`
252          :class:`LegacyVersion` to be used as a stand in for a :class:`Version`.
256          A boolean value indicating whether this :class:`LegacyVersion`
265          :class:`LegacyVersion` to be used as a stand in for a :class:`Version`.
269          A boolean value indicating whether this :class:`LegacyVersion`

pradyunsg · 2021-02-28T15:22:06Z

I believe the docs need to be adjusted (I grepped for "legacy"):

Oooooo! We need to run doctest in our CI. :)

brettcannon · 2021-03-02T00:12:22Z

The points made by @jdufresne all make sense to me.

brettcannon · 2021-03-29T21:57:40Z

@pradyunsg any reason not to merge this once you have a chance to fix the merge conflicts?

pradyunsg · 2021-03-29T22:09:16Z

Documentation updates, but nothing other than that

If someone else can get to updating this before I can, just say so and pick this up. @brettcannon if that someone ends up being you, you should be able to push to this branch directly too. :)

brettcannon · 2021-07-01T00:45:17Z

We should probably get this merged before we cut a 21.0 release.

uranusjr · 2021-07-01T04:55:46Z

This would have an impact on pip’s type checks, I think. Some parts in pip still rely on those Legacy types, and if this isn’t ready very soon, pip will have trouble updating the type hints to include 21.0 in the next pip release. So either we hurry or this needs to wait a while… (it would be a shame if musllinux needs to wait another three months for this)

pradyunsg · 2021-07-01T20:31:26Z

Actually, I think this has been blocking our release for a while and given that we've not released things like musl stuff and more because of it... I'm inclined to suggest that we defer this to after cutting a release or two.

Does that sound stupid or reasonable?

brettcannon · 2021-07-01T21:17:33Z

I'm fine with deferring, but then when can we definitely take out these legacy classes? I just want to make sure that if we are postponing for pip that we do make sure pip is able to update appropriately so we don't drag this out (we do have people accidentally using these classes still, so extended delay wouldn't be great).

pradyunsg · 2021-07-01T21:32:42Z

when can we definitely take out these legacy classes?

I think once there's a pip release with whatever stuff we have merged right now. Basically, I think there's a bunch of tiny details to figure out here, and we can tackle them in a more relaxed manner if there's no "pip release is this month" pressure here.

because LegacyVersion is deprecated. closes #180.

di · 2021-09-14T00:59:57Z

@pradyunsg There's been several pip releases since your last comment, is pip in a place where it could handle the removal of these classes now?

uranusjr · 2021-09-14T02:30:36Z

Not as far as I’m aware.

### Summary & Motivation We were using `packaging.parse` to compare mysql server versions, which broke when `0.23.0` was released with dropped support for `LegacyVersion`. This rolls our own custom version compares to find minimum supported versions, which is tolerant of non semver compliant version strings. The regex parses all the numeric values, and does tuple int comparisons. Reported in #11794 Reference links: pypa/packaging#407 ### How I Tested These Changes Added some test cases that override the server version string to exercise the parsing logic.

The jboss.container.maven.35.bash module cause an Invalid version error with python-packaging to version >= 22, for further details see pypa/packaging#407

- this release does not add any new functionality nor modify existing functionality - **SUMMARY** - see commit 21bd027 for the initial attempt at fixing the upload error - this change fixed the upload error, but changed the functionality of `python_requires` since any `3.0.N` version of python would become incompatible with this change - see commit d3e02a7 for the proper fix to the original upload error while maintaining compatibility for any `3.0.N` version of python - **EXPLANATION (taken from pull request thread)** After doing some digging, this is the likely culprit for what caused this problem: - pypa/packaging#407 - which was the result of pypa/packaging#566 (related: pypa/packaging#530 and pypa/packaging#321) - which in turn looks like the result of the discussion at https://discuss.python.org/t/how-to-pin-a-package-to-a-specific-major-version-or-lower/17077/8 It looks like this is the expected behavior as defined in PEP 440 under the [Inclusive ordered comparison section](https://peps.python.org/pep-0440/#inclusive-ordered-comparison): > An inclusive ordered comparison clause includes a comparison operator and a version identifier, and will match any version where the comparison is correct based on the relative position of the candidate version and the specified version given the consistent ordering defined by the standard [Version scheme](https://peps.python.org/pep-0440/#version-scheme). Following the link to the [Version scheme](https://peps.python.org/pep-0440/#version-scheme) section and looking at the specification under the [Public version identifiers](https://peps.python.org/pep-0440/#public-version-identifiers) section: > The canonical public version identifiers MUST comply with the following scheme: > `[N!]N(.N)*[{a|b|rc}N][.postN][.devN]` > Public version identifiers MUST NOT include leading or trailing whitespace. > > Public version identifiers MUST be unique within a given distribution. > ... The last line included above seems to be the "loose implementation" of the version modifier that the issues and pull requests I linked to at the very top were discussing ("After doing some digging, this is the likely culprit for what caused this problem"). Once that "loose implementation" was fixed, any package that didn't follow the PEP 440 specification for version identifiers broke. In this package, the break occurred because of the `>=3.0.*` comparison, which IS NOT unique within a given distribution, as opposed to `>=3` (what commit d3e02a7 does), which IS unique within a given distribution. To clarify: it looks like the problem we see in this issue is because of implementation fixes in the packaging tools to more closely follow PEP 440, specifically **"Public version identifiers MUST be unique within a given distribution."** Any package that relied on the previous implementation that loosely verified the PEP 440 specification but did not strictly follow PEP 440 broke after the implementation of the packaging tool(s) were fixed to more closely follow PEP 440. More explicitly (from [this comment](https://discuss.python.org/t/how-to-pin-a-package-to-a-specific-major-version-or-lower/17077/8) on the [How to pin a package to a specific major version or lower](https://discuss.python.org/t/how-to-pin-a-package-to-a-specific-major-version-or-lower/17077) discussion): > Christopher already made the response I was going to make: for PEP 440 as written, using wildcards outside of “==” and “!=” comparisons isn’t valid. > > Allowing them for “>=” and “<=” would be reasonable, but it would involve a PEP to fix the spec. (It wasn’t a conscious choice to exclude them, we just didn’t notice at the time that the inclusive ordered comparison operators weren’t formally defined as combining an exclusive ordered comparison with a version match, so the tools have been written to ignore the wildcard instead of paying attention to it) > > Making a coherent definition wouldn’t be too hard: just ignore the wildcard for the exclusive ordered comparison part and keep it for the version matching part. Here are some other posts that aren't directly relevant, but might be interesting tangents for anyone interested in packaging problems: - https://stackoverflow.com/questions/19534896/enforcing-python-version-in-setup-py - https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires - https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#package-data - https://setuptools.pypa.io/en/latest/userguide/datafiles.html - https://peps.python.org/pep-0345/#requires-python - https://stackoverflow.com/questions/8795617/how-to-pip-install-a-package-with-min-and-max-version-range - https://python3statement.org/practicalities/ - https://discuss.python.org/t/requires-python-upper-limits/12663/20 - https://stackoverflow.com/questions/13924931/setup-py-restrict-the-allowable-version-of-the-python-interpreter/13925176#13925176

Since we are only using parse_version for comparison (typically checking that we are greater than some minimum version for tool or package), one would think we can use packaging.version.parse as if it was parse_version Unfortunately, this requires conforming to PEP-440 version definitions, which does not work for e.g. autotools (2.72d) nor older openssl (1.1.1p). We rely in these (and to be sure other) cases on the LegacyVersion behavior. https://packaging.python.org/en/latest/specifications/version-specifiers/#summary-of-differences-from-pkg-resources-parse-version "This specification purposely restricts the syntax which constitutes a valid version while pkg_resources.parse_version attempts to provide some meaning from any arbitrary string." In order to have the least impact to the overall code, we instead add packaging_legacy to requirements.txt and use packaging_legacy.version.parse as if it was parse_version. https://pypi.org/project/packaging-legacy/ pypa/packaging#407 Since pypi.org itself is depending on packaging_legacy (in fact, a pypi dev developed the package), we can expect it to be supported for quite some time. pypi/warehouse#13500 [YOCTO #15348] Signed-off-by: Tim Orling <tim.orling@konsulko.com>

22.0 dropped LegacyVersion: pypa/packaging#407 This makes it so our branches can no longer be parsed as versions

* readthedocs: update config * pin packaging==21.3 - 22.0 dropped LegacyVersion: pypa/packaging#407 - This makes it so our branches can no longer be parsed as versions

22.0 dropped LegacyVersion: pypa/packaging#407 This makes it so our branches can no longer be parsed as versions

pradyunsg added packaging.version packaging.requirements packaging.specifiers labels Feb 28, 2021

pradyunsg mentioned this pull request Feb 28, 2021

Add protocol type BaseVersion #400

Closed

brettcannon approved these changes Mar 2, 2021

View reviewed changes

yan12125 mentioned this pull request Mar 20, 2021

Remove support for LegacyVersion pypa/setuptools#2497

Closed

pradyunsg mentioned this pull request Mar 29, 2021

20.9: test suite warnings #418

Closed

jpmckinney mentioned this pull request May 17, 2021

Using csvkit with Python3.9 produces DeprecationWarning's wireservice/csvkit#1112

Closed

brettcannon added the infrastructure label Jul 1, 2021

brettcannon mentioned this pull request Jul 1, 2021

Release 20.10 #439

Closed

uranusjr mentioned this pull request Jul 1, 2021

Re-implement Git version parsing with regex pypa/pip#10117

Merged

pradyunsg marked this pull request as draft July 3, 2021 12:09

yan12125 referenced this pull request in lilydjwg/nvchecker Jul 18, 2021

vendor packaging.version for our own use

606b3f6

because LegacyVersion is deprecated. closes #180.

frenck mentioned this pull request Aug 22, 2021

InvalidVersion on importing ytmusicapi AppDaemon/appdaemon#1336

Closed

This was referenced Aug 22, 2021

This is a Python issue, there are multiple issues created around different Python projects about this. AppDaemon/appdaemon#1339

Closed

Replace usage of pkg_resources with importlib_resources sigma67/ytmusicapi#223

Closed

neutrinoceros mentioned this pull request Aug 31, 2021

MNT: migrate away from packaging.version.parse yt-project/yt#3494

Merged

samtygier-stfc mentioned this pull request Jan 3, 2023

Mantid Imaging not starting packaging.version.InvalidVersion mantidproject/mantidimaging#1652

Closed

twu mentioned this pull request Jan 3, 2023

Invalid specifier error twu/skjold#169

Open

This was referenced Jan 19, 2023

Investigate breakage with setuptools=66 (DNM) conda/conda-build#4732

Closed

setuptools 66 breaks conda-build conda/conda-build#4733

Closed

prha mentioned this pull request Jan 27, 2023

stop using python semver parsing for mysql versions dagster-io/dagster#11868

Merged

di mentioned this pull request Feb 1, 2023

Unpin constraint on packaging pypi/warehouse#12920

Closed

aoirint mentioned this pull request Feb 2, 2023

非推奨化されたdistutils.versionへの依存をなくし、python-semverに移行する VOICEVOX/voicevox_engine#609

Merged

stanislavlevin mentioned this pull request Feb 10, 2023

Build fails against setuptools 67.0.0 389ds/389-ds-base#5642

Closed

ryanking13 mentioned this pull request Feb 24, 2023

Upgrades packaging version to v23.0 and micropip to 0.2.2 pyodide/pyodide#3605

Merged

leo60228 mentioned this pull request Apr 3, 2023

Incompatible with latest packaging (and thus latest Nixpkgs) DavHau/mach-nix#549

Open

paterit mentioned this pull request Apr 23, 2023

packaging modul from version 22.00 doesn't support version.LegacyVersion paterit/version-checker#30

Open

shailshouryya mentioned this pull request Jun 16, 2023

Fix parsing error on python_requires >=3.0.* by simplifying to >=3 shailshouryya/save-thread-result#3

Merged

awais786 mentioned this pull request Dec 4, 2023

Upgrading packing openedx/edx-repo-health#456

Open

heerener added a commit to neuronsimulator/nrn that referenced this pull request Feb 5, 2024

pin packaging==21.3

b95b892

22.0 dropped LegacyVersion: pypa/packaging#407 This makes it so our branches can no longer be parsed as versions

heerener added a commit to neuronsimulator/nrn that referenced this pull request Feb 5, 2024

pin packaging==21.3

bd57b4e

22.0 dropped LegacyVersion: pypa/packaging#407 This makes it so our branches can no longer be parsed as versions

heerener mentioned this pull request Feb 5, 2024

pin packaging==21.3 neuronsimulator/nrn#2707

Merged

heerener added a commit to neuronsimulator/nrn that referenced this pull request Feb 5, 2024

pin packaging==21.3 (#2707)

8e483a9

22.0 dropped LegacyVersion: pypa/packaging#407 This makes it so our branches can no longer be parsed as versions

JCGoran pushed a commit to neuronsimulator/nrn that referenced this pull request Feb 7, 2024

pin packaging==21.3 (#2707)

b04ca30

22.0 dropped LegacyVersion: pypa/packaging#407 This makes it so our branches can no longer be parsed as versions

zangruochen mentioned this pull request Mar 26, 2024

Upgrade packaging to 24.0 pypa/pip#12598

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Drop `LegacySpecifier` and `LegacyVersion` #407

Drop `LegacySpecifier` and `LegacyVersion` #407

pradyunsg commented Feb 28, 2021 •

edited

jdufresne commented Feb 28, 2021 •

edited

jdufresne commented Feb 28, 2021

pradyunsg commented Feb 28, 2021

brettcannon commented Mar 2, 2021

brettcannon commented Mar 29, 2021

pradyunsg commented Mar 29, 2021 •

edited

brettcannon commented Jul 1, 2021

uranusjr commented Jul 1, 2021

pradyunsg commented Jul 1, 2021 •

edited

brettcannon commented Jul 1, 2021

pradyunsg commented Jul 1, 2021

di commented Sep 14, 2021

uranusjr commented Sep 14, 2021

Drop LegacySpecifier and LegacyVersion #407

Drop LegacySpecifier and LegacyVersion #407

Conversation

pradyunsg commented Feb 28, 2021 • edited

jdufresne commented Feb 28, 2021 • edited

jdufresne commented Feb 28, 2021

pradyunsg commented Feb 28, 2021

brettcannon commented Mar 2, 2021

brettcannon commented Mar 29, 2021

pradyunsg commented Mar 29, 2021 • edited

brettcannon commented Jul 1, 2021

uranusjr commented Jul 1, 2021

pradyunsg commented Jul 1, 2021 • edited

brettcannon commented Jul 1, 2021

pradyunsg commented Jul 1, 2021

di commented Sep 14, 2021

uranusjr commented Sep 14, 2021

Drop `LegacySpecifier` and `LegacyVersion` #407

Drop `LegacySpecifier` and `LegacyVersion` #407

pradyunsg commented Feb 28, 2021 •

edited

jdufresne commented Feb 28, 2021 •

edited

pradyunsg commented Mar 29, 2021 •

edited

pradyunsg commented Jul 1, 2021 •

edited