remove setuptools test command

[branchvincent]

setuptools==72.0.0 just removed their test command so this import now fails

[sethmlarson]

@nateprewitt @sigmavirus24 I don't know if this /needs/ a release, users installing from wheels should be unaffected. Mostly seems like it's affecting folks installing from git.

[eli-schwartz]

Installing from git is only one way to hit the issue... It affects people using pip install --no-binary :all: as well.

[sethmlarson]

@eli-schwartz Right, but Requests being a pure-Python package I hope that most people aren't installing from the sdist. I believe it's also possible to downgrade setuptools so users can install this way if needed in a pinch.

[nateprewitt]

I think the temporary solution is to downgrade setuptools, we already slated for moving to pyproject.toml in the next release which would have already included this change. I would have probably waited until we resolve #6767 and #6757 but this is fine. I highly doubt this still has notable usage outside of maybe distro maintainers.

[eli-schwartz]

@eli-schwartz Right, but Requests being a pure-Python package I hope that most people aren't installing from the sdist. I believe it's also possible to downgrade setuptools so users can install this way if needed in a pinch.

I highly doubt this still has notable usage outside of maybe distro maintainers.

Linux distros are unconditionally installing from the sdist, and as far as they are concerned there is nothing to discuss.

Of course, 50 different organizations can all backport this patch, one by one, individually... :) and indeed one can question whether this has "notable" usage. If not too much time passes before the next release, then not all those distros will even notice the issue if they have existing installable .deb or .rpm releases. Other distros, especially distros which build from source by default (e.g. Gentoo) will definitely notice immediately.

People using pip install --no-binary :all: may be using it because they expect all sdists to validly build ("who uploads broken sdists to PyPI anyway") and want to ensure that all sdists which happen to ship compiled C extensions are built fresh, using system libraries instead of auditwheel vendored ones. There are other reasons to use --no-binary, but this is definitely one of them. And those people would not necessarily be expecting that requests specifically should be built from an sdist, but babysitting every single recursive dependency in their stack would be a lot of pain for zero gain. They "could" go fix up all their CI / release scripts to manually exclude requests, but it would be... disruptive. :)

Again, maybe such people don't count as "notable usage".

[eli-schwartz]

we already slated for moving to pyproject.toml in the next release which would have already included this change. I would have probably waited until we resolve #6767 and #6757 but this is fine.

What's the timeframe for the next release? Is there likely to be one in the next week? Next month? Will it take 12 months? :D The existing tag history leads me to think I shouldn't attempt to read anything into its cadence.

[nateprewitt]

This patch will likely now go out prior to the next minor version release which is when we've announced a move to pyproject.toml. I would anticipate a release with this update to be in the coming weeks depending on availability.

[nateprewitt]

@eli-schwartz and for the record, this change was already reverted pypa/setuptools@441799f.

[eli-schwartz]

Aha, that is convenient. Not much to do then.