Introducing a `pkg_resources` package for `setuptools >=82` compatibility

[mgorny]

Your question:

Setuptools 82 removed the pkg_resources package. However, a lot of packages out there still require it. Right now, feedstocks are starting to pin setuptools <82 which is a suboptimal solution.

Upstream has shown some understanding for the request to package it separately back in February, but things didn't move much from there.

To ease things on CF side, I'd like to propose creating our own pkg_resources package with the code from setuptools 81.0.0 release. The way I see it, we could either:

• create it as a separate feedstock
• create it as an additional output in setuptools-feedstock

Either way, I'm willing to step up as the maintainer. In the latter case, I'd propose branching setuptools-feedstock at 81.0.0, and creating a new build split to two outputs: setuptools and pkg_resources. For backwards compatibility, setuptools 81.0.0 would then run-depend on pkg_resources.

In my opinion, the two important advantages of doing that would be:

1. Avoiding proliferating the pin all over the place.
2. Avoiding a run-dependency on whole setuptools (additionally pinned to an old version) where only pkg_resources are necessary.

If upstream eventually releases a separate pkg_resources package, we can replace our own with it.

Disclaimer: I've done the same thing in Gentoo, and it has worked well for us so far.

CC @conda-forge/setuptools

[rgommers]

I'm not opposed, however I'm personally fine with the <82 pin. It's probably the easiest solution (since a new conda-forge-specific pkg-resources package also needs a recipe change), and it will better match upstreams compared to a CF-only fix.

If upstream eventually releases a separate pkg_resources package, we can replace our own with it.

This is kinda important - adding a new package before upstream catches up is quite reasonable. But will setuptools maintainers actually do this? If they don't, it seems less ideal to do it as CF-only.

[mgorny]

But will setuptools maintainers actually do this? If they don't, it seems less ideal to do it as CF-only.

Hard to tell. However, I wouldn't be that worried about CF-only; since it was always a separate Python-level package, it provides a clear boundary for splitting. It has a separate test suite too. Also, there are at least few other projects doing that, and I honestly think they'll be more, as people hit impossible constraints when the package requires setuptools >=82 but one of the other dependencies requires pkg_resources.

[rgommers]

Also, there are at least few other projects doing that,

Hmm interesting. I'd be inclined to do wait-and-see for a bit. But I think either option is defensible, and it won't be too hard to reverse if needed - so I'll defer to others if they have a stronger opinion.