Removal of LegacyVersion and LegacySpecifier

[pradyunsg]

This issue is an obvious follow up to #321. I'm mostly filing this to serve as the issue that the changelog points to, for coalescing the discussion/planning for this change into a single location, and for having the PR close an issue. :)

---

>>> # before 22.0
>>> packaging.version.parse("This is a completely random string")
<LegacyVersion('This is a completely random string')>

>>> # after 22.0
>>> packaging.version.parse("This is a completely random string")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]/.venv/lib/python3.10/site-packages/packaging/version.py", line 52, in parse
    return Version(version)
  File "[...]/.venv/lib/python3.10/site-packages/packaging/version.py", line 197, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: 'This is a completely random string'

This "feature" has been deprecated (#321) for nearly two years as of April 2022.

PyPI has not permitted uploading packages with invalid versions for even more years. The latest versions of pip should be rejecting/erroring out on wheels with such versions as well. The stricter metadata validation helps pip's dependency resolver's logic, along with helping the broader ecology avoid needing to deal with outside-of-standard tooling/behaviours.

For users who might be impacted by this, they have hopefully caught this issue in (a) their test suites, (b) through the "warnings" presented during the execution of legacy code, during the deprecation period, or (c) as part of warnings presented by pip.

Users who encounter breakage due to this change can adopt the following broad strategy for dealing with it:

1. Pin to an older version of packaging (or pip, if your error contains pip._vendor.packaging in the traceback), to deal with the immediate breakage.
2. Modify the versions / specifiers that they use, to be compatible with PEP 440's specification. In practice, this means that if your Requirement/Version/Specifier can be parsed by the Requirement, Version or SpecifierSet classes from this package, it can be used going forward. Notably, you won't be able to compare between legacy versions outside of the === arbitrary-equality operator.
3. Update their development/deployment processes to catch deprecation warnings before they become breakages in their workflows, or to mitigate the propagation of potentially-breaking-changes upstream making it into their development workflows.

If there's anything we can do to help you catch these issues earlier, please write your suggestion in a comment with a 💡 emoji in it (:bulb:). :)

[pradyunsg]

This is what the pip warnings/errors should look like, to users:

  WARNING: Built wheel for awesome-test-package is invalid: Metadata 1.2 mandates PEP 440 version, but 'magickarp' is not

[pradyunsg]

Pinning this for visibility, since this has now been released.

[pombredanne]

While I agree this was a good idea, dropping LegacyVersion is still creating quite a bit of churn for several of my packages and the packages that depend on these. In particular tools that process PyPI packages in a generic way using packaging will fail for older packages that use legacy versions. An important aspect of such tool is to compare versions, and failing to process and sort the whole set of versions of a package is problematic. pytz is an example where old versions such as 2004d fail with v22 and up.

Basically, pip and other packaging tools will fail processing the whole PyPI package index and this is a use case where processing the legacy past is a feature.

For now I ended up coping with adding a https://github.com/nexB/pip-requirements-parser/blob/main/src/packaging_legacy_version.py for instance (as this would otherwise break pip-audit and scancode-toolkit) ... and I am considering either:

• create a lib of this packaging_legacy_version.py
• create a packaging2 library as a soft fork that tracks packaging but still support LegacyVersion

I am looking for help or ideas there 💡 !

[pradyunsg]

I've said this elsewhere: folks are welcome to create a lnient-version library on PyPI that takes the LegacyVersion / LegacySpecifier objects from the last release as-is and makes it available for reuse.

[Semnodime]

The lasting use of LeagacySpeifiers has detrimental impact on intuitive pipenv usability when parsing a Pipfile with a typo pypa/pipenv#4247.

@erdnaxeli When using an invalid version range like >=x=x,<y, Pipenv does not complain.