-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Using canonicalize_version from _vendor instead of extern breaks packages #4496
Comments
I have a public project that exhibits this. My downstream issue: https://gitlab.com/plom/plom/-/issues/3491 CI failure example: https://gitlab.com/plom/plom/-/jobs/7385812246 (Haven't spent any time looking at what's happening here other than it started when 71.0.0 came out and still happens on 71.0.3). |
Simple example doesn't reproduce bugI couldn't reproduce it when just doing it on a simple setup.
I also have a more complex dockerfile I can't share, that has the issue. Here's the stacktrace anyway: reproducible example (although more complicated code, involving another projects scripts)
stack trace of bug
|
[while typing this @ben-xD posted another example] I started trying to make a MWE. But instead here's an example that I think is roughly equivalent to my project but it doesn't fail... more digging required:
|
Ok I can reproduce it without my full project like this:
which dies like this:
I'll see if I can narrow down that package list a bit more... |
Narrowed it down to this MWE:
|
@cbm755 We ran into this too. The issue for us was that Disclosure: I'm just a random person on the internet and have nothing to do with pypa or |
Thanks @mikealfare yes my MWE has |
This issue is a duplicate of #4483. I'll pin that issue for extra visibility. |
… release Use newest `packaging` to avoid packaging incompatibility with `setuptools>=71.0` As pypa/setuptools#4496 (comment) mentions: > setuptools>=71.0 does not work with packaging<24.0, but will not upgrade it if packaging is already installed Also relevant: pypa/setuptools#4496
… release Use newest `packaging` to avoid packaging incompatibility with `setuptools>=71.0` As pypa/setuptools#4496 (comment) mentions: > setuptools>=71.0 does not work with packaging<24.0, but will not upgrade it if packaging is already installed Also relevant: pypa/setuptools#4496
… release Use newest `packaging` to avoid packaging incompatibility with `setuptools>=71.0` As pypa/setuptools#4496 (comment) mentions: > setuptools>=71.0 does not work with packaging<24.0, but will not upgrade it if packaging is already installed Also relevant: pypa/setuptools#4496
Temporary fix for #3491. See also [1]. [1] pypa/setuptools#4496
Follow fix from pypa/setuptools#4496 and pin `setuptools` dependency to v70.3.0 to work around breaking change made in v71.
Follow fix from pypa/setuptools#4496 and pin `package` dependency to v24.1 to work around breaking change made in `setuptools` v71.
This fixed the issue for me, thanks! |
setuptools version
setuptools==71.0.0, setuptools==71.0.1, setuptools==71.0.3
Python version
Python 3.10.0
OS
Ubuntu
Additional environment information
This is happening when installing internal packages at my firm which I cannot share, but am happy to get answer general questions.
Description
Since version 71.0.0 release, some of our services which depend on internal packages have been breaking, and all the errors are precisely this one:
Appears to be an issue with moving from .extern.packaging.utils.canonicalize_versions to setuptools .vendor.packaging.utils.canonicalize_version (as that is the change from version 70.3.0 -> 71.0.0 from what I can see in the setuptools diff, related to canonicalize_version).
Expected behavior
This happened while installing the internal packages in the docker environment for our service.
How to Reproduce
Steps to reproduce are a little difficult here, as I cannot provide the internal package.
Output
The text was updated successfully, but these errors were encountered: