Delay dropping support for LegacyVersion

[pombredanne]

Dear packaging maintainers:
This warning comes up "Creating a LegacyVersion has been deprecated and will be removed in the next major release" but there is an important use case which is to parse versions in the wild including old ones (in a scanning tool like ScanCode toolkit).

So it would be great to keep support for LegacyVersion in packaging as I consider packaging as the reference library for tools and not only the library that supports only the latest and greatest supported specs.

Alternatively, if you do really plan to remove it, I could start a fork of packaging for this purpose, but IMHO this would defeat having a shared packaging library in the first place.

[pradyunsg]

See #321. This package is intended for use for parsing Python versions, and not arbitrary versions. LegacyVersion was a holdout to help ease the migration, which is now deemed complete-enough.

I could start a fork of packaging for this purpose

Please feel free to! I'd suggest going lighter-weight and creating the package with only the logic that's currently in LegacyVersion, since IIUC, that's your usecase.

[brettcannon]

I agree with @pradyunsg , so I'm going to close this issue.

[pombredanne]

This works: Thank you guys!

[uranusjr]

Could you also drop a word here when (if) you create that package? I could use that abstraction for several things I maintain; currently I’m using regex and would welcome anything that makes the logic more maintainable.

[pombredanne]

@uranusjr I sure will!

FWIW, The primary usage is for https://github.com/nexB/univers which is a first implementation of this upcoming mini spec https://github.com/package-url/purl-spec/blob/013eb68c496eee6c1d6ac3fe5042a46b8017ef68/VERSION-RANGE-SPEC.rst

I will likely fold this in the univers library since this is the primary one with the dependency on packaging. If you think this is useful standalone for others that may depend on it I can surely make this a separate standalone library too. ... please advise!

And key other usages that depend on packaging version parsing are listed below since they deal with Python packages metadata parsing and data collection in various capacities:

• Adopt nexB/skeleton and bump dependencies aboutcode-org/scancode-toolkit#2818 for improved Python versions handling and this also include setup.py ast-based parsing, various metadata parsing and bring all the other related libraries below together in https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/pypi.py to eventually collect the metadata of any python package, including legacy.

• pip-requirements-parser at https://github.com/nexB/pip-requirements-parser which is a new mostly correct pip requirements parser that uses pip's own code, forked and reorged.

• dparse2 at https://github.com/nexB/dparse2 for tox, conda, Pipfile/lock, and some level of setup.py

• pkginfo2 at https://github.com/nexB/pkginfo2 for bdist/sdist/wheel and a few more

• https://github.com/nexb/vulnerablecode through the univers library for Pypi version ranges

[pradyunsg]

If you think this is useful standalone for others that may depend on it I can surely make this a separate standalone library too.

I think it is!

I'm pretty sure there's other folks who depend on legacy version "just working" and having a lenient-version library or something that those users can easily adopt is a nice migration path.