dependency conflict

[wellshs]

Pypa released new packaging library version(https://github.com/pypa/packaging/releases/tag/22.0) and legacyVersion is deleted which used in this pip-requirements-parser library.

Currently, this code doesn't work without additional library version fixing.

[tetsuo-cpp]

Just FYI, I'm also working on a PR to get pip-requirements-parser to work with packaging>=22.0.

[pombredanne]

@tetsuo-cpp @wellshs Thanks... I knew this was coming and had been altered to the issue by the packaging maintainers! This is breaking pip audit but also projects at CycloneDX and pretty much all the projects at https://github.com/nexB
@tetsuo-cpp the short term solution is IMHO to vendor the legacyversion support

[pombredanne]

@tetsuo-cpp we can chat live on https://gitter.im/aboutcode-org/discuss accessible via IRC, web, matrix.
Or on IRC #pypa

[tetsuo-cpp]

I'm going to be offline for a few hours. But I'll sign on later and see if you're around.

Is it possible to just remove support for LegacyVersion? I assume that everything that uses packages to interpret versions (such as pip) are going to drop support for this going forward so I figured it should be fine to drop this from the parser.

[pombredanne]

Is it possible to just remove support for LegacyVersion? I assume that everything that uses packages to interpret versions (such as pip) are going to drop support for this going forward so I figured it should be fine to drop this from the parser.

It could be possible, but this would make fail requirements parsing at scale for all the legacy stuff out there. This lib is supposed and designed to parse all requirement files ever published for the whole PyPI history and beyond.

We should have a way to skip legacy though

[pombredanne]

@tetsuo-cpp do you have something/some WIP to push in a branch?
Otherwise I am pushing something myself ASAP.

[tetsuo-cpp]

I do have something but it just removes references to 'LegacyVersion' and updates tests which isn't what you had in mind. Sure, go ahead!

[pombredanne]

See #3 for a pending fix.
I vendored (with git history) the LegacyVersion

[pombredanne]

There are some tests that fail... so short term, let me pin an upper version in the setup.cfg

[pombredanne]

@wellshs @tetsuo-cpp I pushed a v32.0 to PyPI.... can you test this in your context?
Thanks!

[tetsuo-cpp]

@pombredanne Thanks! v32.0 works fine for pip-audit.

Would you like me to test against #3 too?

[pombredanne]

@tetsuo-cpp re: testing #3
this would be great!
There are some tests that I am still trying to fix though... I reckon that I combined here the tests suite of pip plus all requirements parsers known to man.... some may be a bit overkill or off broadway.

[wellshs]

Hi again!, I'm using this library through bentoml.
Recent patch of bentoml add upper bound of packaging for now.

I tested install pip-requirements-parser directly or install through bentoml. Both install pip-requirements-parser==32.0.0 and packaging 21.3. So, I believe this issue won't appear any more.

Thanks for fixing this issue so quickly! @pombredanne @tetsuo-cpp

I will close this issue, because this issue was solved!

[tetsuo-cpp]

@tetsuo-cpp re: testing #3 this would be great! There are some tests that I am still trying to fix though... I reckon that I combined here the tests suite of pip plus all requirements parsers known to man.... some may be a bit overkill or off broadway.

That branch seems to be working fine with pip-audit.

I just gave it a try on some a few requirements files I had lying around and ran our test suite. If you want me to do some more rigorous testing prior to release, I'm happy to help with that.

[pombredanne]

I am keeping this open for now until we have a permanent fix that works nicely with packaging 22 and up

[pombredanne]

@wellshs bentoml looks awesome! Note that if you need a bit more than requirements parsing we have also a full stable of parser including for our belove Python package manifests menagerie, including setup.py in https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/pypi.py and if needed we could extract this in a separate lib... and there is a dependency resolution utility in https://github.com/nexB/python-inspector

[ViktorHaag]

I am keeping this open for now until we have a permanent fix that works nicely with packaging 22 and up

Yes, please; tox now needs pinning in an environment to cohabit with pip-audit and pip-requirements-parser, as its latest versions insist on packaging at at least version 22.

[priv-kweihmann]

@pombredanne is there any timeline when a fixed version would be available? - I tried cherry-picking a version from your test branch, but due to the inline merge commits, it’s almost impossible to even compile a local patch that would enable running the code in combination with packaging 22.x

[priv-kweihmann]

FYI: I created a patch based on 32.x release that unblocks my local setup (https://github.com/priv-kweihmann/meta-sca/blob/master/recipes-python/python-pip-requirements-parser-native/files/0001-add-vendored-packing-module.patch) - interesting side note is that the tagged version 32.x (priv-kweihmann@1b90b63) needs a different patch than the same based on the sdist release from pypi - not entirely sure why, but the requirements.txt is different in git vs sdist.

Good news is that functionality wise the proposed vendoring does the trick

[pombredanne]

@priv-kweihmann Thank you++
... I am eventually forking packaging because there is too much churn see aboutcode-org/scancode-toolkit#3171 and
https://pypi.org/project/packaging2/ and pypa/packaging#530 ... though the name is not final

[priv-kweihmann]

@pombredanne eagerly waiting on a release with packaging2 then ;-) - please make sure that original packaging and your fork can be installed in the same venv/rootfs, as this will be still a requirement for all the setups I maintain

[pombredanne]

@priv-kweihmann it will be renamed packvers based on a request of the packaging maintainer to avoid confusion.

please make sure that original packaging and your fork can be installed in the same venv/rootfs, as this will be still a requirement for all the setups I maintain

Yes that's the whole point.

[pombredanne]

for now, I am going to keep the vendored LegacyVersion here and use the standard packaging otherwise either v21 or v22. packvers will be used for more involved dependencies handling and processing in python-inspector, univers and scancode-toolkit