-
-
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 |
- python-Levenshtein insecure, upgraded to 0.12.1 - Upgrade setuptools==74.1.0 to address TypeError bug pypa/setuptools#4483 - Add ref value to django-uk-political-parties - - Address security risk in futures<0.18.2 and some flask versions GHSA-m2qf-hxjv-5gpq - Loosen versions of setuptools, werkzeug, click to address conflicts - Add certifi as a missing subdependency
py39 jobs (on ubuntu-focal) started to fail due to recent virtualenv release (20.26.4 that bundles setuptools 74.1.2) on Yoga, because we have 'packaging==21.3' in this branch that is not compatible with the new 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. [1] pypa/setuptools#4483 Change-Id: I668557933c51123ce84275a0c718b6e79b3df174
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. [1] pypa/setuptools#4483 Closes-Bug: #2082234 Change-Id: I08e57e3b4c905bd679038c89185e54f6ab79738a
setuptools version is pinned to 70.3.0 to resolve an issue related to this ticket: pypa/setuptools#4483 pylint version is forced to >=3.3.0, where max-positional-arguments functionality has been added and max-positional-arguments is set to 16: pylint-dev/pylint#9842 Changes in functional test test_stateless_sec_group_list_find because sec group lists from a sec group can be ordered differently each time a request is sent to obtain them. Changed custom_mtu_size default value from 1350 to 1300 because some tests started failing on some jobs with: "Requested MTU is too big, maximum is 1314" Change-Id: Ie92d9a2f4e0dd08aeadfd720bdf4963b532decf3
Using setup.py to build and execute tests is no longer recommented, this change to python based dockerfiles uses `pip install .` to ensure the install process works and `unittest` to run the unit tests. Besides that, `packaging` had to be upgraded to become compatible with the setuptools>71, which breaks backwards compatibility (see 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. [1] pypa/setuptools#4483 Change-Id: Icd7a5e7bb0941513e7ab5a778ee3811740f38028
py38 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. Note, that we also have to cap it explicitly, otherwise tox somehow pulls in latest setuptools. [1] pypa/setuptools#4483 Change-Id: Id9e02f8b26bad5e2ef74908012de0b81898c04d0
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. [1] pypa/setuptools#4483 Change-Id: Icd7a5e7bb0941513e7ab5a778ee3811740f38028 (cherry picked from commit 9bc2b3c)
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. [1] pypa/setuptools#4483 Change-Id: I294f6715c41fd1651e92f41c6601880c19f442a7
Thanks it worked |
Why do I need to downgrade to 70.0.0? This is nuts... |
did you try this? |
Downgrading setuptools or adding packaging with a specific version as a dependency are both weird. The docs just say that people need to add setuptools as a build dependency, nothing about packaging. If setuptools depends on packaging, and it is incompatible with older versions of packaging, then @jaraco how is this behavior "by design"? What I see in the docs does not help. |
A recent release of setuptools breaks when packaging is <22.0 [0]. Because we can't reliably pin setuptools in the real world (we expect people to simple create a venv and pip install from there (with our without tools like tox) we update our stable constraint to 23.1 to match stable/2023.2 in order to get things working again. [0] pypa/setuptools#4483 Change-Id: If75a86941b636580b5220f9ea5fa80a12d1bf2e6
There is an incompatibility between packaging version from CentOS and setuptools from pip. Which causes a failure running the tests: TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero' See also pypa/setuptools#4483 Fix this by using a the current packaging version instead of the CentOS packaged one. Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be>
There is an incompatibility between packaging version from CentOS and setuptools from pip. Which causes a failure running the tests: TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero' See also pypa/setuptools#4483 Fix this by using a the current packaging version instead of the CentOS packaged one. Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be>
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: