[BUG] Version 78.0.1 breaks install of ansible-vault package #4910
Comments
|
We are circumventing this by excluding setuptools 78.0.1. Update: That was a thought, but it does not work reliably. See the discussion below. |
|
Seeing this for other packages as well. |
|
Hi @andy-maier, please contact the package developers and inform about the problem highlighted in the error message:
This has been deprecated in 2021. |
It looks like there are issue with the new release: pypa/setuptools#4910
|
Hello, having the same issue with https://pypi.org/project/opentracing/ where the project is not maintained anymore, we'll try to get rid of it, but would be great to keep it backward compatible, if possible :) Thank you! |
|
@abravalheri I can do that, but I do not understand why this issue comes up now, just 30min after 78.0.1 was released, and the same packages worked before. There must have been some change that "activated" that check only now. |
You are absolutely correct, there was. |
|
Update: Downgrading setuptools to below 78.0.1 does not make the error go away. That is consistent with @abravalheri stating that the check was introduced in 2021. So it must be something else. Any idea where to look? |
|
We had the same issue with pysdf which is also no longer maintained, but used by us. Had to manually run |
|
Our system broke here as well. Downgrading to 77.0.3 did not fix it for us. |
|
We are on |
|
We have the same issue with multiple third-party packages. Downgrading to |
Before 78.0.0, there should be a deprecation warning. After 78.0.0, this deprecation warning was converted to an exception. Sometimes it can be a bit tricky to pin the setuptools version because of caching and/or build isolation. You can try to use (78.0.0 and 78.0.1 are identical when it comes to user-facing code, the only difference is in the CI code). |
|
The problem is that it does not seem to be clearly tied to the setuptools versions that are used. At one point I thought it is related to whether or not pip's |
See pypa/setuptools#4910 for more details
|
I understand how you have had this deprecation warning since 2021, but I'm not sure the rest of the community has caught on to this change. Others have mentioned this happens in a package that is no longer maintained but we are experiencing this in a repo that is still active olirice/alembic_utils#153 Is it reasonable to force everyone to make this change by breaking their application builds? |
|
Both we and sentry i see (https://github.com/getsentry/sentry-python/pull/4192/files) are trying all the suggestions presented here and none of them work. As long as none of us know why our setups are failing it's hard to prescribe the correct solution. Both pinning with a constraints file and other versions of pinning setuptools has no effect. |
Coming back to this... It seemed to work when doing it manually. But all our automatons seem to break |
|
This is pretty bad and hitting a large amount of packages, please consider yanking this as soon as possible. |
|
|
|
The issue pops up for any package that still uses the deprecated Caching may render the issue hard to reproduce: if you or your CI agent locally has access to a pre-built version of the affected package, the issue won't pop-up. There is only one option right now for fresh installs: install an earlier version of setuptools and disable build isolation. This affects very mainstream packages, such as |
|
Hitting this for several dependencies as well. Concretely, EDIT: We're using Poetry 2.1.1. |
|
The only explanation I can understand here is that installing pip itself drags in the unpinned latest version of setuptools, and this is hard or impossible to override. The only good solution here is to yank 78.0.1 from Pypi. |
This is obvious. But the job of us - users of the open-source software done by volunteers is to help them succeed. If every single person who commented "you should not do it" would go to their dependencies - like I did - and tell them "improve" - and spend their time and energy in leading that, this is the only way how to drive down those 12.000 packages down to maybe a handful in a year or two. And we can help. Those people in the packaging team working on it do all the contributions here in their free time - away of their families and day jobs. They work nights and weekends and sometimes, it happens that they make mistakes. Are we all responsible enough, and can raise up to the task of helping those people to succeed in the future and thank them for the hard work they do? Or all that we are capable of is to tell what THEY should do and how much they screwed up? Unlike rolling your own sleeves up and spending your own time on making things better, that is not helpful nor constructive. I would really love if that experience turns into all those 100s of people who looked and watched that issue into agents of change who will help the whole ecosystem to modernize their build systems. Are you up to the challenge? I am and i am going to do so. I hope many of other people here will do it as well. |
And ... just to let everyone know: this works - and I am going to create a PR fixing And yes anyone else can also change and improve the world and go to their dependencies they saw failing and help to fix them. Maybe we can all show the power of Python community and - for a change - help to fix things rather than just complain? |
Is your recommendation that maintainers of all affected libraries release new patch versions for every minor version they've released in recent years to remove a dash? New versions of libraries should use current best practices, but a core build tool needs to be able to interact with old versions as well. The setuptools team do great work for the community, but they should be encouraged to avoid predictable (and predicted) large-scale disruption. |
I don't argue that preventing predictable disruption is a good idea. I 100% agree with you. But that does not preclude spending effort by people like you and others to:
What I am asking for is that it's quite a good idea by everyone affected here not to "negatively" complain on things but "positively" improve the world around them. Clean your own beach. This is a theme that I am actively working with Alpha-Omega team on "Airflow Beach Cleaning" project - you can watch the Airflow Summit Keynotte from October 2024 where we explain it with Michael Winser what we are trying to do and encourage others: https://www.youtube.com/watch?v=f6gfoVJXWEE Yes, This is a long and multi-year effort, but if we all, as community, get used to helping others who we depend on and start doing it regularly and do it at scale, problems like that will be far less often and we will be able to leave the world quite a bit better than when we started. BTW. It's not always easy to predict such things - in case of But if you look at my talk - just reaching out is already a good time spent by you and others because you might find out that when you have such problematic dependency, you can do one of three F's
This is what I propose here:
Anyone from any project can do it. And it's pretty much our moral obligation towards all our dependencies that we build our value on, to make sure that we also care about them (because your security and availabilty depends on your engagement with your dependencies). And yes. You can change the world. We already did in quite a number of cases in Airflow Beach Cleaning - I am going to share more and more findings and results of it as it progresses. |
This removes all of the Murano code that is deprecated in the 3.0.0 release. When rally pulls in Murano it also pulls python-muranoclient that depends on murano-pkg-check that is old code that was also shown to fail the new setuptools version [1] that removed support for dashes in setup.cfg that has been deprecated since 2021. [1] pypa/setuptools#4910 Change-Id: Icb69c77f96fbf10be0def5be9e21c9af8f57761b
* Update rally-openstack from branch 'master'
to 109bf1e5598db5637a3f4f446e8a3415140e8b2a
- Remove Murano
This removes all of the Murano code that is
deprecated in the 3.0.0 release.
When rally pulls in Murano it also pulls python-muranoclient
that depends on murano-pkg-check that is old code that
was also shown to fail the new setuptools version [1]
that removed support for dashes in setup.cfg that has
been deprecated since 2021.
[1] pypa/setuptools#4910
Change-Id: Icb69c77f96fbf10be0def5be9e21c9af8f57761b
|
There are too many comments here but in case people didn't mention this earlier, make sure to read this blog post on handling dependency upgrades reliably: https://hynek.me/articles/semver-will-not-save-you/#taking-responsibility. |
adamcallison is not talking about the latest versions. they are talking about the ability to install older versions. requoting with emphasis:
the setuptools breakage in this issue affects more than the latest version
none of the advice in that post is relevant to this issue. see #4910 (comment) to understand why |
|
@raylu agreed. Not sure if here is the right place to discuss this, but I think this is exposing a key vulnerability in python build systems. When building an app, a requirements.txt or simliar can easily pin exact versions of libraries in order to guarantee a level of stability. But for python libraries that serve as build backends (like setuptools, flit or hatch) - those aren't subjected to any such pins. Ideally, build backends would specify a range like "build_tool>3.4,<=4.2", but all it takes is for a single library maintainer to fail to do this, and an applications build process is theoretically unstable. This comment thread is nearing 5000 comments, so clearly affected a whole bunch of people. I don't think we'd see anywhere near this affect if setuptools was a standard library (rather than a build backend) - it'd just be a case of "fix the deprecation or pin". It's easy to get frustrated at maintainers of tools like setuptools when we percieve that as being the "thing that's broken my build process" - but all things considered, they did a pretty good job communicating on a deprecation (several years), and then pragmatically rolling back when things didn't work. The honus is maybe on tools like pip/uv, and us as a community, to work towards something better than just requiring tools like setuptools have 100% backwards compatibility. Especially if we want maintainers of things like this to be able to continually improve their libraries without burning out. |
@raylu that's not true. pip-tools can be used to generate a constraint file for the (transitive) build deps specifically. I personally merged a pull request implementing it quite a while ago: https://pip-tools.rtfd.io/en/stable/#maximizing-reproducibility. Using that is a bit unobvious, but setting the |
setuptools version
78.0.1
Python version
3.11
OS
Ubuntu
Additional environment information
No response
Description
When installing the "ansible-vault" package, setuptools raises this exception:
Expected behavior
ansible-vault has not changed since 2021 and should install as before.
How to Reproduce
Output
See above
The text was updated successfully, but these errors were encountered: