tempfix: pin setuptools

[jvanasco]

We are under 60 days from the planned removal of pkg_resources. I worry about the impact of this on CI and Automatic Deployments.

I suggest releasing a tempfix to pin setuptools, which will ensure anyone who has not independently pinned setuptools within their projects is not affected by this, as work continues on #3731 .

[luhn]

I submitted #3787 and #3788 a couple months ago but haven't heard anything—Although I neglected to update the changelog so your PR is better.

[jvanasco]

I'm sorry for not seeing that.

I thought about offering a backport , but figured I'd address this first. Why don't you pull my changelog onto both of your PRs (or at least the backport) ? We can leave this open so it's at the top of the list so it keeps visibility until yours are merged (or another solution happens?)

[luhn]

No worries, I'll just close my PR and we can keep the better+fresher one.

I'll add a changelog to my backport and keep it open though, it'd be nice to keep Pyramid 1 working OotB as long as possible. I still have a couple projects using it.

[jvanasco]

I still have some legacy stuff running on pyramid1 too, but I think it's mostly unported py27 so unaffected by all this.

[aquatix]

Hey all! Thanks for looking into this. As stated, we're just shy of a month away from this deprecation, and I was wondering if a release with this change will be available before then. Otherwise we will have to pin some libraries ourselves, which is also not a big deal, but having Pyramid handle this itself would be nice.
Is it much work to eliminate the need for pkg_resources in general by the way?

[mmerickel]

You should pin your dependencies.... With respect to removing pkg_resources you can catch up on #3731.

[jvanasco]

You should pin your dependencies....

That is standard practice. Pinning a dependency's dependencies (i.e. pyramid's dependencies) is not.

We're about 3 weeks out from this potentially breaking CI and installs.

@luhn My contingency plan right now is to switch to our forks (my v2, your v1). I did a test, and I can entirely automate the switchover for all our affected code - and revert it as well. Introducing a setuptools requirement is too messy, as the package might already require it for something else.

[sbrunner]

This should really resolve the issue: #3783

[19emtuck]

a recent update of setuptools package 82.0.0 add a problem on top of this pile. pkg_resources has been removed from setuptools and now pyramid tests crashes because of src/pyramid/asset.py file line 2 (import pkg_resources)

ImportError while loading conftest '/builds/my_app/tests/conftest.py'. tests/conftest.py:7: in <module> from pyramid import testing /root/.cache/pypoetry/virtualenvs/my-app-F1dxTj3i-py3.11/lib/python3.11/site-packages/pyramid/testing.py:7: in <module> from pyramid.config import Configurator /root/.cache/pypoetry/virtualenvs/my-app-F1dxTj3i-py3.11/lib/python3.11/site-packages/pyramid/config/__init__.py:8: in <module> from pyramid.asset import resolve_asset_spec /root/.cache/pypoetry/virtualenvs/my-app-F1dxTj3i-py3.11/lib/python3.11/site-packages/pyramid/asset.py:2: in <module> import pkg_resources E ModuleNotFoundError: No module named 'pkg_resources'

[luhn]

We should change the constraint to <82, since 81 still works fine.

[luhn]

As a pedantic note, we aren't technically pinning, as that means specifying the exact version, we're just adding a version constraint.

[jvanasco]

OK, done. I would have just accepted @merwok's stuff as a commit, but I had to open my copy because @luhn wanted to get all pedantic on us ;)