pkg_resources should be a separately-distributed package

The pkg_resources module provides some functionality which is need during the "runtime" of a package, while setuptools' functionality is only required during the build. For not having to depend on the full setuptools egg, it would be good to provide an pkg_resources egg which packages can depend on.

It's a good idea, but not immediately feasible due to bootstrapping issues.

You mean, there's a bit of a chicken-and-egg problem? <groan/>

Yes. The issue that #581 seeks to address.

Now that issue #581 is closed what is needed to implement this request?

Any update on this issue? Our library depends on pkg_resources at runtime but we prefer not to add the whole setuptools as a dependency.

pkg_resources should present its own package, but it's difficult to do. I don't even know it's feasible, but I'm working on it in pypa/pkg_resources and the feature/vendor-pkg-resources branch of setuptools.

Since PyCon 2018, I've been focusing on the importlib_metadata project. This work might still proceed, but it's less important if importlib_metadata can largely obviate the need for pkg_resources.

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.

(Coming from #5181 (comment)).

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.

Apologies to chip-in, I have re-opened the discussion because it seems that the situation described is indeed something that OS distributions and downstream re-packagers are hitting. So I think that it is worth at least to keep the discussion open until we have a clarification on the topic.

It's not just OS packagers: as noted on #5174, this also affects projects maintaining stable branches for communities such as OpenStack. We only maintain the last 4 release nowadays (< 2 years old) but still, virtually all of our stable branches are now broken. pkg_resources was only deprecated for removal 9 months ago. While we have all issues fixed on master, some of the rework was significant and we haven't backported these fixes everywhere. We also have limited to no ability to fix packages that we don't control (like a great many Sphinx extensions, for example). Fixing those branches requires 3 * N changes, where N is the number of projects we have to fix (virtually all of them fwict).

This fix also doesn't help where pkg_resources is used as a build-time dependency. From what I can tell, this approach would force use of --no-build-isolation since the new --build-constraint option and PIP_BUILD_CONSTRAIN envvar only constrains dependencies in the build environment: it does not allow you to inject new ones. Projects relying on setuptools and pkg_resources at build-time (for e.g. old school namespace packages, or if using pbr) will obviously not have pkg_resources listed in build-system.requires, whether they have an in-tree pyproject.toml or are relying on the fallback defined in PEP-517.

will obviously not have pkg_resources listed in build-system.requires, whether they have an in-tree pyproject.toml or are relying on the fallback defined in PEP-517.

The solutions are not mutually exclusive.

One possibility if pkg_resources is available on PyPI, could be to inject it as a build dependency via the get_requires_for_build_{sdist,wheel} build hooks, but just for the __legacy__ backend. This is something that can be debated, has pros and cons.

will obviously not have pkg_resources listed in build-system.requires, whether they have an in-tree pyproject.toml or are relying on the fallback defined in PEP-517.

The solutions are not mutually exclusive.

One possibility if pkg_resources is available on PyPI, could be to inject it as a build dependency via the get_requires_for_build_{sdist,wheel} build hooks, but just for the __legacy__ backend. This is something that can be debated, has pros and cons.

I had written off this possibility since I imagine it would require an amendment to PEP-517, since pip is not the only game in town nowadays.

I had written off this possibility since I imagine it would require an amendment to PEP-517, since pip is not the only game in town nowadays.

No amendment is needed. Setuptools can return whichever list of dependencies it wants as the output of the hook (as long as it does not create cycles), and the frontend should install it.

I had written off this possibility since I imagine it would require an amendment to PEP-517, since pip is not the only game in town nowadays.

Now amendment is needed. Setuptools can return whichever list of dependencies it wants as the output of the hook (as long as it does not create cycles), and the frontend should install it.

Fair, though that will still leave everyone using e.g. distro-provided pip / virtualenv / uv in a broken state until the distro picks up the change. It also leaves packages that had migrated to pyproject.toml but were using pkg_resources (directly or indirectly, as a build-time dependency or a run-time dependency) in a broken state. This isn't personally an issue for me (hence my original title/suggestion in #5174) but it's worth considering. Lastly, there's the question of cost for this approach (PEP amendment, changes to multiple frontends etc. - none of which will be addressed in days or even weeks) versus the benefits (the pkg_resources directory no longer exists in the root of the repo, and you remove 7 lines from pytest.ini and a single line from pyproject.toml). I think you can guess what side of that debate I come down on.

Strike that. I'd misunderstood what you were suggesting. I believe this is effectively what I'd originally suggested in #5174. If this works then I'd have no issues with this approach.

If/when uploaded to PyPI, hopefully the new PEP 792 “deprecated” marker can be immediately applied to keep helping with the status visibility !

Hey, as a Alpine Linux developer, I'm also very much in favor of distributing pkg_resources seperately as https://github.com/pypa/pkg_resources. I've also opened pypa/pkg_resources#20 to clarify the license, which is the same as setuptools.

Hello, as a Fedora developer I would also appreciate having pkg_resources as a standalone package. The latest setuptools breaks more than 100 packages (out of 4000) on buildtime only and possibly more on runtime.

And now packages are transitively pinning to setuptools<82 at runtime to workaround this breakage.

And now we have packages that actively require setuptools >= 82.0.1 to build (e.g. types-python-dateutil), and fail to build when older version is used instead. So we're effectively in the worst case scenario.

In Fedora we have decided to create python-setuptools80 compat package so maintainers can decide which version theirs packages want to use. We will have both versions of setuptools living side by side and we will retire the compat package once nothing depends on it. Maybe you could do something similar in Gentoo?

Not really. If you can't install both simultaneously, it can't work for us. We could create an artificial pkg-resources package and install it from old setuptools sources, but if there's a plan for having an official package, we'd rather wait for that before we accidentally diverge and cause mayhem.

Is anything likely to happen with this soon? I'm working on switching OpenBSD ports to newer setuptools, currently using https://pypi.org/project/standard-pkg-resources/ (https://github.com/stephenfin/standard-pkg_resources) but would switch if there's something official.

Navigation Menu

Repository navigation

pkg_resources should be a separately-distributed package #863

4 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

pkg_resources should be a separately-distributed package #863

Description

Activity

jaraco commented on Nov 29, 2016

warsaw commented on Nov 29, 2016

jaraco commented on Jan 1, 2017

bignose-debian commented on Jul 25, 2017

haotianw465 commented on Jan 11, 2018

jaraco commented on Mar 17, 2018

jaraco commented on Apr 4, 2019

jaraco commented on Feb 8, 2026

4 remaining items

stephenfin commented on Feb 10, 2026

abravalheri commented on Feb 10, 2026

stephenfin commented on Feb 10, 2026

abravalheri commented on Feb 10, 2026

stephenfin commented on Feb 10, 2026

Avasam commented on Feb 12, 2026

fossdd commented on Feb 15, 2026

hrnciar commented on Feb 23, 2026

mgorny commented on Feb 25, 2026

mgorny commented on Mar 24, 2026

hrnciar commented on Mar 24, 2026

mgorny commented on Mar 24, 2026

sthen commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions