-
-
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] TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero' #4483
Comments
Issue is visible when you use packaging<22.0 |
Could reproduce the same issue. Fixed by downgrading to 70.x |
Also it can be fixed by update packaging to 22.0 or higher |
This behavior is by design. Similar to the issue reported in #4478, the new Setuptools 71 will prefer installed dependencies over the vendored ones. You'll want to either uninstall the older (incompatible) dependencies from the environment or install these dependencies. |
Just to confirm, we're seeing this happen in this environment: python -m pip install --upgrade pip
python -m pip install --upgrade setuptools wheel twine check-wheel-contents Is that correct? It sounds like you're saying the issue is old dependencies existing in the environment, but we should have the most current packages here. |
Thanks @jaraco this was helpful. In my project where I was having the issue because on older version of It's a bit annoying that the behaviour of setuptools changed which messed up my tests (which gets the latest version of setuptools when setting up) but that is very much my fault and not your teams. Again, thanks for your comment as it helped my to understand the issue better and what the cause was. For anyone who has a situation like me where my tests just started failing I'd check to make sure your dependancies and the dependancies of setuptools are compatible. |
Thanks for posting your solution. I'm trying to reason through how we're running into the same issue. We're not specifying |
This is now necessary since `setuptools >= 71` started preferring externally present stdlib deps over the vendored ones. Refs: * pypa/setuptools#4457 * pypa/setuptools#4483 * pypa/setuptools#2825
Yes, probably.
Agreed, it is a bit of a sharp corner, and we made the major release as a signal of this shift in expectations. The issue is that while you're holding it correctly and
I think I may have been too cautious about this advice. We specifically want to avoid packages themselves making this declaration in |
@jaraco Thanks for taking the time to respond. This advice is super useful:
The issue that we wound up running into is that older versions of our package actually take a runtime dependency on |
py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. Furthermore, lower-constraints jobs are not supported anymore and are removed from most of the branches, so let's remove here as well to unblock the gate. [1] pypa/setuptools#4483 Change-Id: I866b7cd97462edcd501e26b4c6cce6069c58ee90
py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. Furthermore, lower-constraints jobs are not supported anymore and are removed from most of the branches, so let's remove here as well to unblock the gate. [1] pypa/setuptools#4483 Change-Id: If0011cd6f814f5ec6f3e19fb893d29eed8e6c814
1. Use OVS main branch git checkout of OVS master branch causes an error [1]. OVS deleted its master branch and replaced it with main branch. 2. Cap setuptools <71.0.0 py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. 3. Remove lower-constraints job lower-constraints jobs are not supported anymore and are removed from most of the branches, so let's remove here as well to unblock the gate. [1] error: pathspec 'master' did not match any file(s) known to git [2] pypa/setuptools#4483 Change-Id: I010e145f4c5079a80b72c5229dfacc4d6896373e
py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. Furthermore, lower-constraints jobs are not supported anymore and are removed from most of the branches, so let's remove here as well to unblock the gate. [1] pypa/setuptools#4483 Change-Id: I0a9d955e711c3f5095071e1fac5f3fe472ddcbd6
1. Use OVS main branch git checkout of OVS master branch causes an error [1]. OVS deleted its master branch and replaced it with main branch. 2. Cap setuptools <71.0.0 py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. 3. Remove lower-constraints job lower-constraints jobs are not supported anymore and are removed from most of the branches, so let's remove here as well to unblock the gate. [1] error: pathspec 'master' did not match any file(s) known to git [2] pypa/setuptools#4483 Conflicts: zuul.d/project.yaml NOTE(elod.illes): conflict was due to branch specific job template Change-Id: I010e145f4c5079a80b72c5229dfacc4d6896373e (cherry picked from commit f2d7949)
1. Use OVS main branch git checkout of OVS master branch causes an error [1]. OVS deleted its master branch and replaced it with main branch. 2. Cap setuptools <71.0.0 py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. 3. Remove lower-constraints job lower-constraints jobs are not supported anymore and are removed from most of the branches, so let's remove here as well to unblock the gate. [1] error: pathspec 'master' did not match any file(s) known to git [2] pypa/setuptools#4483 Conflicts: zuul.d/project.yaml NOTE(elod.illes): conflict was due to branch specific job template Change-Id: I010e145f4c5079a80b72c5229dfacc4d6896373e (cherry picked from commit f2d7949) (cherry picked from commit 1a49de7)
1. Use OVS main branch git checkout of OVS master branch causes an error [1]. OVS deleted its master branch and replaced it with main branch. 2. Cap setuptools <71.0.0 py38 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. NOTE(elod.illes): lower-constraitns job template is not added in victoria branch, but the wrong version of python jobs were used. This patch updates the zuul config to use victoria version of the python job template. [1] error: pathspec 'master' did not match any file(s) known to git [2] pypa/setuptools#4483 Conflicts: zuul.d/project.yaml Change-Id: I010e145f4c5079a80b72c5229dfacc4d6896373e (cherry picked from commit f2d7949) (cherry picked from commit 1a49de7) (cherry picked from commit c49ea28)
Looks like I'm running into this issue specifically on windows/python3.8: pypa/setuptools#4483
py39 jobs (on ubuntu-focal) started to fail due to recent virtualenv release (20.26.4) on Yoga (which bundles setuptools), because we have 'packaging==21.3' in this branch that is not compatible with newer setuptools [1]. setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. This patch also sets to use keystone-tempest-plugin from wallaby-last tag for functional jobs otherwise they fail [2] as on newer versions of keystone-tempest-plugin keystoneauth is set as >=5.1.1 in requirements.txt however we pin keystoneauth in upper-constraints.txt much lower version than that. [1] pypa/setuptools#4483 [2] ERROR: Cannot install keystone-tempest-plugin==0.17.0 because these package versions have conflicting dependencies. The conflict is caused by: keystone-tempest-plugin 0.17.0 depends on keystoneauth1>=5.1.1 The user requested (constraint) keystoneauth1===4.5.0 Change-Id: I76c39af6119806631d800ad644db270dd7d01b64
sel4-deps have started to fail installation on GitHub CI, although they seem to work fine on clean Ubuntu 22.04. See the saga on pypa/setuptools#4483 Signed-off-by: Gerwin Klein <[email protected]>
sel4-deps have started to fail installation on GitHub CI, although they seem to work fine on clean Ubuntu 22.04. See the saga on pypa/setuptools#4483 Signed-off-by: Gerwin Klein <[email protected]>
Required to avoid pypa/setuptools#4483
Issue in setuptools: pypa/setuptools#4483 Related commit in packaging: pypa/packaging@e99b37e
Issue in setuptools: pypa/setuptools#4483 Related commit in packaging: pypa/packaging@e99b37e
The related commit in packaging is pypa/packaging@e99b37e if anyone needs a reference (and 22.0 is correct). |
Install instructions for `setuptools` pip packages changed. https://setuptools.pypa.io/en/latest/userguide/quickstart.html Removes CI issues of this kind: pypa/setuptools#4483 (comment)
The pip instructions for setuptools require now to specify the `[core]` argument, otherwise dependent packages are used from the system and are usually outdated, which causes errors. X-ref: - https://setuptools.pypa.io/en/latest/userguide/quickstart.html - pypa/setuptools#4483 (comment)
Periodic stable jobs are meant for stable branches and not for unmaintained branches. perioid-weekly is enough (if there is anyone, who checks its result) to keep. This patch removes all periodic-stable jobs. This patch also removes networking-sfc from required projects in zuul.yaml as unmaintained/zed and older branches do not exist anymore for this repository. Furthermore, in this branch we have to cap as well networking-sfc to avoid incompatibilities with current neutron version. Lower constraints are not used and tested anymore in most of the OpenStack projects so it doesn't make sense to maintain it here, hence the job is removed and the lower-constraints.txt as well. Also include this patch to unblock the gate: Cap setuptools <71.0.0 py39 jobs (on ubuntu-focal) started to fail (see the relevant github issue [1]) due to recent virtualenv release (20.26.4; which bundles setuptools). setuptools is bundled in virtualenv, so it has to be capped via the virtualenv package. tox also needed to be capped (<4) as gate uses tox 3.28.0, but with capping virtualenv we pull in latest tox as well, which would cause other errors. [1] pypa/setuptools#4483 Conflicts: .zuul.yaml Change-Id: I085f3343e1466f43e4318055e252347000397f0f (cherry picked from commit 79b2d92) (cherry picked from commit 4570f681ec7873d854dbca32508008c292315491)
These fix #158 on my system, but we might instead want to drop the venv requirements entirely (#161)? The underlying issue is pypa/setuptools#4483. When using setuptools>=71.0.0 and packaging<22.0, setuptools may fail with `TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero'`. The code in these projects seems innocent enough, so I can't fully rule out some system configuration issue on my machine. I did see that error on both Python 3.12 and Python 3.13 though. I made a reasonable attempt at building https://github.com/ROCm/rocBLAS/ from source standalone to report an issue there, but there are no CMake instructions for the project, only monolithic `install.sh` and `rmake.py` scripts that I don't trust (outside of Docker -- `install.sh` is filled with side-effecting commands).
setuptools version
setuptools>=71.0.0
Python version
Python 3.12
OS
Ubuntu
Additional environment information
I found this bug when running the test for the project in GitHub actions
Description
When I install the requirements in my Python package project (
pip-sync requirements-dev.txt
) I get an error within setuptools which says:This error was caused by using setuptools >= 71.0.0
Not to speculate but it looks like the issue was introduced by this commit in setuptools: 00384a5
And this commit is including new changes from the packaging project and its this commit here where we can see the issue:
pypa/packaging@cc938f9
https://github.com/pypa/packaging/blame/4493dfcd95a893f676a7aa4bd17c547bea676371/src/packaging/utils.py#L58
Expected behavior
I would expect
pip-sync requirements-dev.txt
to run successfullyHow to Reproduce
Clone https://github.com/tim-s-ccs/example-python-package.git
Make sure you are using Python 3.12 and you have pip-tools installed (
pip install --upgrade pip wheel pip-tools
)Make sure you are using the correct version of setuptools
pip install --upgrade setuptools==71.0.0
Run
pip-compile requirements-dev.in
Output
The text was updated successfully, but these errors were encountered: