As some of you have probably noticed already, setuptools 82 removed pkg_resources. While I’m not opposed to the decision per se, I’m slightly worried about the fallout from the removal. In particular, I’m looking for some coordination on how we handle it.
Of course, ideally projects would migrate away from pkg_resources. However, obviously this will not always happen, especially for projects that aren’t maintained anymore. In Gentoo, I don’t really want to either be forced to maintain a significant bundle of patches to random projects, nor to pin setuptools < 82 all over the place.
I could technically introduce a Gentoo-local package that reintroduces pkg_resources separately for the time being, but I’d like to hear if the wider Python community doesn’t plan on introducing a similar package anyway, so I don’t end up duplicating the work.
Historically, these things would be split out into their own modules so that they can remain in use for projects that need that API. Has someone done that yet for pkg_resources?
There’s a suggestion of introducing a standalone pkg_resources package, but plan A is for old projects to pin Setuptools:
In #3085, there was a lot of discussion about creating this separately distributed package. There are some impediments to supporting that approach (mainly, requesting to unblock the name in PyPI), but also it may be that it’s not necessary. I’d like to first explore the possibility of simply dropping it and environments that require it at runtime will pin to older setuptools.
Therefore, I’ll close this issue for now.
If it turns out that pinning Setuptools doesn’t provide a suitable bridge (those environments need newer versions of Setuptools or are unable to downgrade), we can revive this effort.
Speaking on behalf of the PyPI team, I don’t think this is an actual impediment as I see no issue releasing the pkg_resources name to the setuptools maintainers and this could be done immediately (it appears that this was originally namesquatted by @dstufft for this purpose in 2013, but I see no record of any request for the name since then).
Good timing on this thread, since I just ran into an error due to this. An older dependency[1] relied on pkg_resources and they didn’t pin setuptools so it will no longer install.
Once Github works again I can try to submit a fix, but I don’t know that they’re maintaining this code anymore. It would be handy if I could manually override their build dependencies in my project but that seems like a uv feature request.
I think the last commit was in 2023, but Github is having its own problems this morning ↩︎
Yeah, I’d prefer pkg_resources as a package sooner than later, even if it turns out to be unnecessary in the long term. That is, before people start creating their own pkg_resources name-forks for the same purpose, to workaround the name block.
I have no memory of doing this, but if pkg_resources is under my name, then yea absolutely (or if it’s in the banned list, then obviously yes as well ).
Excluding downstream re-packagers, I think that this document discusses tooling drift and a future-proof way to go for people that depend on build-time behaviour of pkg_resources (e.g. people that use a old dependency on their github workflow or application CI):
(apologies for the link not being rendered on the website, waiting for Github).
The project is currently ‘prohibited’ on PyPI but this is only a matter of transferring the name to one (or more) setuptools maintainers. Generally we ask that name requests go through this process, I think it’d be OK to expedite this given the stated time constraint here.
Thanks for bringing this up. We’d probably appreciate a broken-out pkg_resources package for Debian too. Pinning isn’t an option for a Linux distro, either we stick with the old version, or push forward with the new one.
We have already pushed hard to get packages off pkg_resources but the long tail is long. All the unmaintained packages you speak of…
).