Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[BUG] TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero' #4483

Closed
tim-s-ccs opened this issue Jul 18, 2024 · 36 comments

Comments

@tim-s-ccs
Copy link

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:

Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error

× python setup.py egg_info did not run successfully.
...
TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero'

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 successfully

How 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

    error: subprocess-exited-with-error
    
    × python setup.py egg_info did not run successfully.
    │ exit code: 1
    ╰─> [42 lines of output]
        running egg_info
        creating /private/var/folders/kt/n16_msf56_z3kfyb65l37wxhb_m4s_/T/pip-pip-egg-info-3sca_19y/example_python_package.egg-info
        writing /private/var/folders/kt/n16_msf56_z3kfyb65l37wxhb_m4s_/T/pip-pip-egg-info-3sca_19y/example_python_package.egg-info/PKG-INFO
        writing dependency_links to /private/var/folders/kt/n16_msf56_z3kfyb65l37wxhb_m4s_/T/pip-pip-egg-info-3sca_19y/example_python_package.egg-info/dependency_links.txt
        writing top-level names to /private/var/folders/kt/n16_msf56_z3kfyb65l37wxhb_m4s_/T/pip-pip-egg-info-3sca_19y/example_python_package.egg-info/top_level.txt
        writing manifest file '/private/var/folders/kt/n16_msf56_z3kfyb65l37wxhb_m4s_/T/pip-pip-egg-info-3sca_19y/example_python_package.egg-info/SOURCES.txt'
        reading manifest file '/private/var/folders/kt/n16_msf56_z3kfyb65l37wxhb_m4s_/T/pip-pip-egg-info-3sca_19y/example_python_package.egg-info/SOURCES.txt'
        Traceback (most recent call last):
          File "<string>", line 2, in <module>
          File "<pip-setuptools-caller>", line 34, in <module>
          File "/Users/my.name/Code/test/example-python-package/setup.py", line 16, in <module>
            setup(
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/__init__.py", line 106, in setup
            return distutils.core.setup(**attrs)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/_distutils/core.py", line 184, in setup
            return run_commands(dist)
                   ^^^^^^^^^^^^^^^^^^
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/_distutils/core.py", line 200, in run_commands
            dist.run_commands()
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/_distutils/dist.py", line 970, in run_commands
            self.run_command(cmd)
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/dist.py", line 974, in run_command
            super().run_command(command)
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/_distutils/dist.py", line 989, in run_command
            cmd_obj.run()
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/command/egg_info.py", line 321, in run
            self.find_sources()
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/command/egg_info.py", line 329, in find_sources
            mm.run()
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/command/egg_info.py", line 555, in run
            self.prune_file_list()
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/command/egg_info.py", line 621, in prune_file_list
            base_dir = self.distribution.get_fullname()
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/_core_metadata.py", line 266, in get_fullname
            return _distribution_fullname(self.get_name(), self.get_version())
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/setuptools/_core_metadata.py", line 284, in _distribution_fullname
            canonicalize_version(version, strip_trailing_zero=False),
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        TypeError: canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero'
        [end of output]
    
    note: This error originates from a subprocess, and is likely not a problem with pip.
Traceback (most recent call last):
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/operations/build/metadata_legacy.py", line 64, in generate_metadata
    call_subprocess(
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/utils/subprocess.py", line 209, in call_subprocess
    raise error
pip._internal.exceptions.InstallationSubprocessError: python setup.py egg_info exited with 1

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/my.name/.pyenv/versions/3.12.2/bin/pip-compile", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/click/decorators.py", line 33, in new_func
    return f(get_current_context(), *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/piptools/scripts/compile.py", line 470, in cli
    results = resolver.resolve(max_rounds=max_rounds)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/piptools/resolver.py", line 604, in resolve
    is_resolved = self._do_resolve(
                  ^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/piptools/resolver.py", line 636, in _do_resolve
    resolver.resolve(
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 76, in resolve
    collected = self.factory.collect_root_requirements(root_reqs)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 538, in collect_root_requirements
    reqs = list(
           ^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 494, in _make_requirements_from_install_req
    cand = self._make_base_candidate_from_link(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 210, in _make_base_candidate_from_link
    self._editable_candidate_cache[link] = EditableCandidate(
                                           ^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 328, in __init__
    super().__init__(
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 158, in __init__
    self.dist = self._prepare()
                ^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 235, in _prepare
    dist = self._prepare_distribution()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 338, in _prepare_distribution
    return self._factory.preparer.prepare_editable_requirement(self._ireq)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/operations/prepare.py", line 698, in prepare_editable_requirement
    dist = _get_prepared_distribution(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/operations/prepare.py", line 72, in _get_prepared_distribution
    abstract_dist.prepare_distribution_metadata(
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/distributions/sdist.py", line 69, in prepare_distribution_metadata
    self.req.prepare_metadata()
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/req/req_install.py", line 580, in prepare_metadata
    self.metadata_directory = generate_metadata_legacy(
                              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/my.name/.pyenv/versions/3.12.2/lib/python3.12/site-packages/pip/_internal/operations/build/metadata_legacy.py", line 71, in generate_metadata
    raise MetadataGenerationFailed(package_details=details) from error
pip._internal.exceptions.MetadataGenerationFailed: metadata generation failed
@tim-s-ccs tim-s-ccs added bug Needs Triage Issues that need to be evaluated for severity and status. labels Jul 18, 2024
@Kaflak
Copy link

Kaflak commented Jul 18, 2024

Issue is visible when you use packaging<22.0

@tonythomas01
Copy link

Could reproduce the same issue. Fixed by downgrading to 70.x

@Kaflak
Copy link

Kaflak commented Jul 18, 2024

Also it can be fixed by update packaging to 22.0 or higher

@jaraco
Copy link
Member

jaraco commented Jul 18, 2024

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. You may be tempted to install setuptools[core], but please avoid doing that as core is an internal implementation detail.

@mikealfare
Copy link

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. You may be tempted to install setuptools[core], but please avoid doing that as core is an internal implementation detail.

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.

@tim-s-ccs
Copy link
Author

Thanks @jaraco this was helpful. In my project where I was having the issue because on older version of packaging was a dependancy (not compatible with setuptools v71.0.0 or maybe earlier). Updating that dependancy did indeed fix the issue.

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.

@mikealfare
Copy link

Thanks @jaraco this was helpful. In my project where I was having the issue because on older version of packaging was a dependancy (not compatible with setuptools v71.0.0 or maybe earlier). Updating that dependancy did indeed fix the issue.

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 packaging anywhere, so I would assume we would get the most current version. And when I install locally, I get the same version of packaging you specify in your PR. Perhaps the CI image I'm using already has packaging installed, but with an older version? I'll investigate and post back if I find something. But it would definitely be a sharp corner if pip install --upgrade setuptools no longer works on ubuntu-latest.

webknjaz added a commit to webknjaz/ansible that referenced this issue Jul 18, 2024
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
@jaraco
Copy link
Member

jaraco commented Jul 18, 2024

Perhaps the CI image I'm using already has packaging installed, but with an older version?

Yes, probably.

Thanks for posting your solution. I'm trying to reason through how we're running into the same issue. We're not specifying packaging anywhere, so I would assume we would get the most current version. And when I install locally, I get the same version of packaging you specify in your PR. Perhaps the CI image I'm using already has packaging installed, but with an older version? I'll investigate and post back if I find something. But it would definitely be a sharp corner if pip install --upgrade setuptools no longer works on ubuntu-latest.

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 pip install -U setuptools should theoretically upgrade all the required dependencies, it cannot currently due to the bootstrapping problem. I'm actively working on solving that issue, but in the meantime, one needs to pip install -U setuptools[core] to prepare an environment safely.

You may be tempted to install setuptools[core], but please avoid doing that as core is an internal implementation detail.

I think I may have been too cautious about this advice. We specifically want to avoid packages themselves making this declaration in build-requires. I believe it's safe to use in systems integration tooling.

@mikealfare
Copy link

@jaraco Thanks for taking the time to respond. This advice is super useful:

You may be tempted to install setuptools[core], but please avoid doing that as core is an internal implementation detail.

I think I may have been too cautious about this advice. We specifically want to avoid packages themselves making this declaration in build-requires. I believe it's safe to use in systems integration tooling.

The issue that we wound up running into is that older versions of our package actually take a runtime dependency on packaging. Upon verifying the package (by installing it), the version of packaging was getting clobbered. This was only causing an issue for the sdist, and not the wheel.

openstack-mirroring pushed a commit to openstack/oslotest that referenced this issue Feb 14, 2025
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: I9a4ef7aa16249a13b8804396c8f4d71cd4566ab3
openstack-mirroring pushed a commit to openstack/python-novaclient that referenced this issue Feb 14, 2025
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: I521660d9ab6996d0ee7b475c5dcd183889a8b14e
openstack-mirroring pushed a commit to openstack/oslo.limit that referenced this issue Feb 14, 2025
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: Ifac6787e2a5b0aed06e19ce8ba4b82a65aa8e80d
openstack-mirroring pushed a commit to openstack/keystonemiddleware that referenced this issue Feb 14, 2025
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.

[1] pypa/setuptools#4483

Change-Id: Ibd9fa8ef4eb7916b72fa6f60efa8dbc3bddaa489
openstack-mirroring pushed a commit to openstack/python-keystoneclient that referenced this issue Feb 14, 2025
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.

[1] pypa/setuptools#4483

Change-Id: I25cea89afa4b74bf003812dad22157f5d62d37e2
openstack-mirroring pushed a commit to openstack/oslo.reports that referenced this issue Feb 15, 2025
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: Ib2d3ff7dbcbbaf8c5bc392f77091bea0a6c25002
openstack-mirroring pushed a commit to openstack/oslo.i18n that referenced this issue Feb 15, 2025
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: If4acb5c8508b478ae036ae58e9b188751deb8af2
openstack-mirroring pushed a commit to openstack/automaton that referenced this issue Feb 15, 2025
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: Ic8725b894a1cd22c0323476284144b8d1d1a4b21
openstack-mirroring pushed a commit to openstack/oslo.concurrency that referenced this issue Feb 15, 2025
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: I8524c5555f57d0b7832f98197d351e1c6b55116d
openstack-mirroring pushed a commit to openstack/oslo.vmware that referenced this issue Feb 15, 2025
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: Ib86410f0f1a26b6519d67df78d9510b638063c6b
openstack-mirroring pushed a commit to openstack/osprofiler that referenced this issue Feb 15, 2025
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: I9c361dfee3a219cf566db95895e119ccff9ff0d5
openstack-mirroring pushed a commit to openstack/debtcollector that referenced this issue Feb 15, 2025
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: I1b5f2e966290c4f5aa87f800f9cb4ae6e84a3889
openstack-mirroring pushed a commit to openstack/python-glanceclient that referenced this issue Feb 15, 2025
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: I883459af0e8bae3b7e2f70ead65ae1e05b2621ba
openstack-mirroring pushed a commit to openstack/oslo.privsep that referenced this issue Feb 15, 2025
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: Iaf465de70a03e34824da6aff3288d5fa8197e262
openstack-mirroring pushed a commit to openstack/oslo.middleware that referenced this issue Feb 15, 2025
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: I607dc7f5394bc9d711744913d5d2c46bb19d56df
openstack-mirroring pushed a commit to openstack/oslo.rootwrap that referenced this issue Feb 15, 2025
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
openstack-mirroring pushed a commit to openstack/ironic-ui that referenced this issue Feb 16, 2025
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
openstack-mirroring pushed a commit to openstack/ovsdbapp that referenced this issue Feb 16, 2025
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
openstack-mirroring pushed a commit to openstack/keystoneauth that referenced this issue Feb 16, 2025
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
openstack-mirroring pushed a commit to openstack/ovsdbapp that referenced this issue Feb 16, 2025
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)
openstack-mirroring pushed a commit to openstack/ovsdbapp that referenced this issue Feb 16, 2025
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)
openstack-mirroring pushed a commit to openstack/ovsdbapp that referenced this issue Feb 16, 2025
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)
tristanlatr added a commit to tristanlatr/docstring_parser that referenced this issue Feb 19, 2025
Looks like I'm running into this issue specifically on windows/python3.8: pypa/setuptools#4483
openstack-mirroring pushed a commit to openstack/keystone that referenced this issue Feb 26, 2025
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
lsf37 added a commit to seL4/ci-actions that referenced this issue Feb 27, 2025
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 <gerwin.klein@proofcraft.systems>
lsf37 added a commit to seL4/ci-actions that referenced this issue Feb 27, 2025
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 <gerwin.klein@proofcraft.systems>
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests