The pypa team are just not capable stewards of core aspects of the python ecosystem. As a maintainer and developer of Python based tools and libraries it is very frustrating having these folks push some change that they want and simply oopsie a significant chunk of the Python ecosystem, and then go dark for hours.<p>They've done it this time by making poor architectural decisions ("Isolated builds should install the newest setuptools") and then add in poor library maintenance decisions ("We'll remove this feature used by thousands of packages that are still in use as active dependencies today"). Possibly each of these decisions were fine in a vacuum, but when you maintain a system that people depend upon like this, you can't simply push this stuff out without thinking about it. And if you do decide to do those things, you can't just merge the code and call it a day without keeping an eye on things and figuring out if you need to yank the package immediately! This isn't rocket science, everyone else developing important libraries in Python world has mostly figured this stuff out. In classic pypa form, it sounds like there was a deprecation warning but it only showed up if you ran the deprecated command explicitly, while the simple presence of this command causes package installs to fail. You have to at least warn on the things that will trigger the error!<p>These days I try to rely on the absolute minimum number of packages possible, in order to minimize my pypi exposure. That's probably good dev practice anyway, but is really disappointing that I can't rely on third party libraries basically at all in Python, when the vast pypi package repository is supposed to be a big selling point of the language. But as a responsible developer I must minimize my pip / setuptools surface area, as it's the most dangerous and unreliable part of the language. Even wrapper tools are not safe, as you see in the thread.
Particularly sad that even projects that attempt to pin their dependencies are running into this issue: if a dependency doesn’t have a pre-built wheel, then it will be built in an “isolated” environment, which means it won’t inherit a pinned setuptools version from the root project, and will instead pull the latest (unless the dependency itself is pinning setuptools).<p>Reproducible builds can’t come too soon.
> This functionality has been deprecated for 5 years<p>I used to think that 5 years is a long time when I was younger... that was before I had to maintain multiple legacy codebases.<p>The biggest problem here is that it's a yet another pinning mechanism (PIP_CONSTRAINT) which most people didn't need[0] to know about until today.<p>[0] <i>need</i> is defined here as 'production works without having to know this'.
It says a lot about the way this tooling is being used that five years of deprecation warnings still isn't enough to get people to port over their software.<p>Perhaps this should've been implemented as a gradual failure with a temporary workaround ("as of X, this feature will break unless you specify the MY_CODE_WILL_BREAK_IN_OCTOBER=1 environment variable" rather than just breaking after an update), though I doubt that would've changed much.
Ugh. I've been trying to get my recently rebuilt desktop compiling a Python program (Redash) today, and it's been refusing to build due to this exact problem.<p>Have spent hours on this, trying to get it working first on my Proxmox desktop, then in VMs, and was now testing in a stock standard Debian VM. It turns out it's an upstream bug.<p>---<p>The steps here (for poetry users) worked for me:<p><a href="https://github.com/pypa/setuptools/issues/4519#issuecomment-2255446798">https://github.com/pypa/setuptools/issues/4519#issuecomment-...</a>
Can we somehow vote to just stop having setuptools be maintained? When it breaks it wasts years of collective developer time and it really doesn't need to change at this point...
For those caught out by this, I put together a Github repo that shows how you can work around it in your Github Actions. Hope it helps! <a href="https://github.com/simonwhitaker/setuptools-demo">https://github.com/simonwhitaker/setuptools-demo</a>
Looks like this was fixed a few hours ago, by the release of a new (patched) version 72.1.0 of setuptools: <a href="https://github.com/pypa/setuptools/releases/tag/v72.1.0">https://github.com/pypa/setuptools/releases/tag/v72.1.0</a>
Looks like Python 2 -> 3 all over again. Something is deprecated for a very long time, people ignore the warning, and then cry foul when the thing is removed. Is there to be no cleanup and advancement in the language/ecosystem?