setuptools: [BUG] latest setuptools release (60.3.0) broke pip?
setuptools version
60.3.0
Python version
Python 3.10 (but also reproduces with other versions)
OS
macOS (but also reproduces in GitHub Actions CI using ubuntu-latest)
Additional environment information
No response
Description
The new version of setuptools that was just released seems to have broken pip? After upgrading to latest setuptools, running pip commands is now failing with an AttributeError.
Expected behavior
Pip continues to work after installing the latest release of setuptools, rather than raising AttributeError.
How to Reproduce
Install the latest release of setuptools (60.3.0), and then run a pip command like pip list
.
Output
jab@tsmbp /tmp> python3 -m virtualenv /tmp/venv
created virtual environment CPython3.10.1.final.0-64 in 269ms
creator CPython3Posix(dest=/private/tmp/venv, clear=False, no_vcs_ignore=False, global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/Users/jab/Library/Application Support/virtualenv)
added seed packages: pip==21.3.1, setuptools==59.5.0, wheel==0.36.2
activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
jab@tsmbp /tmp> . /tmp/venv/bin/activate.fish
(venv) jab@tsmbp /tmp> python -m pip list
Package Version
---------- -------
pip 21.3.1
setuptools 59.5.0
wheel 0.36.2
(venv) jab@tsmbp /tmp> python -m pip install -U setuptools
Requirement already satisfied: setuptools in ./venv/lib/python3.10/site-packages (59.5.0)
Collecting setuptools
Using cached setuptools-60.3.0-py3-none-any.whl (953 kB)
Installing collected packages: setuptools
Attempting uninstall: setuptools
Found existing installation: setuptools 59.5.0
Uninstalling setuptools-59.5.0:
Successfully uninstalled setuptools-59.5.0
Successfully installed setuptools-60.3.0
(venv) jab@tsmbp /tmp> python -m pip list
/private/tmp/venv/bin/python: Error while finding module specification for 'pip' (AttributeError: module '__main__' has no attribute '__file__')
Code of Conduct
- I agree to follow the PSF Code of Conduct
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 24
- Comments: 26 (10 by maintainers)
Commits related to this issue
- Update GitHub Actions setup. Notably, work around bug in latest setuptools release. Ref: https://github.com/pypa/setuptools/issues/3002 — committed to jab/bidict by jab 2 years ago
- Add test capturing failure. Ref #3002. — committed to pypa/setuptools by jaraco 2 years ago
- Merge test with fix. Ref #3002. — committed to pypa/setuptools by jaraco 2 years ago
Yanked 60.3.0.
Setuptools 60.3.1 is going out now.
I chose not to release it last night because I wanted to be alert and around when it’s released, just in case there are other high-impact issues associated.
This caused some massive disruption (yikes!). I’d put too much faith in the test suite, which missed a crucial code path. The fix includes a regression test to ensure this code path is exercised and this issue doesn’t happen again.
Also, please use
requires = ["setuptools!=60.3.0", "wheel"]
if you have to avoid a bug like this in the future - that will not block future fixes, etc, so can be left in, while the pin has to be removed/updated. Don’t worry, bugs will be fixed. 😃Hi @lhupfeldt thank you very much for the feedback, setuptools is working in a new version and it should be available soon.
Meanwhile, please consider the workaround previously discussed (i.e. installing the latest version of
virtualenv
, e.g. viapip
/PyPI
).Please notice that using an outdated version of pip and virtualenv that are not able to handle the “yanked” metadata provided by the index server might interfere (and cause breakages) with other packages (not only setuptools).
It seems the offending commit is likely 41fa663c9da93ca1af98ce2ae397c02e4b3062e8.
Edit: cross-ref discussion at #2993 as well.
Something worth noting perhaps is that what is broken is explicitly
python -m pip
. Example:You can break
python -m pip
withsetuptools
v60.3.0
, butpip
by itself will keep working fine, which is not great (though it does mean that your virtual environment isn’t destroyed forever! 👍).Hi @delicb, would you have a way of reproducing this behaviour? When I tried to install
build
in a brand new virtualenv here and run it against one of my packages, everything seems to be OK.It might be the case the index server/cache-proxy does not handle “yanked” versions very well… If that is true, it would be good to report these issues to them so they can also investigate (just try first updating virtualenv/pip and see if the problem persists…)
I would kindly ask you to bear with us just for a bit, while the new version is not out.
setuptools
has followed the correct protocol in the Python ecosystem, by yanking the problematic version. It is a pity not all tools are ready to interoperate with that.Removing all caches and venvs that I know about did not solve my issue,
60.3
keeps comimng back 😦 A quick re-branding of60.2
as60.3.1
would probably solve the problem and help a lot of people.@abravalheri Thanks for the response. I understand this is 99% due to AWS Code Artifact.
I can not share the project (closed source), but it is a very simple library with the following section in
pyproject.toml
and standard nothing-fancysetup.py
:With those lines,
python -m build
fails withERROR Command '['/private/var/folders/xh/ltk6fjb55zv9ykn3k767lhvh0000gn/T/build-env-tzlc3gel/bin/python', '-Im', 'pip', 'install', '--use-pep517', '--no-warn-script-location', '-r', '/var/folders/xh/ltk6fjb55zv9ykn3k767lhvh0000gn/T/build-reqs-xrd9lz9x.txt']' returned non-zero exit status 1.
.After setting
setuptools==60.2.0
, command passes.As additional test, I have removed index URL from pip config (thus falling back to default PyPI, instead of AWS Code Artifact) and build is successful even when version is not explicitly set. So, it does look like it is AWS Code Artifact Problem (btw, I have tried deleting the 60.3.0 from codeartifact, but it just pops up again).
You are right, I will try to report this problem to AWS. I can check if there is a way to “forbid” some package versions or something similar, but workaround with fixing a version to
60.2.0
works so I might just wait for new version to be rleased.A newer version should probably be released with a fix. Applying workarounds like
--upgrade setuptools==60.2.0
is not feasible in automated builds. E.g. we have an RTD installation in docker, to apply that workaround I would have to hack the docker build. It can also be very difficult to remve all cached versions. I have to cleanup all pip caches on our RTD server plus caching in our pypi proxy.Experiencing this as well. Pinning to the previous setuptools gets around this issue until this is fixed:
@jaraco if you happen to see this before you go offline till tomorrow, would it be worth yanking 60.3.0 off PyPI?
Seen by @matthewfeickert and I as well. https://twitter.com/HEPfeickert/status/1478923370083545089