Remove easy_install and package_index

[jaraco]

Closes #917

• Remove reference in test_windows_wrappers to easy_install.
• Moved some fixtures out of test_easy_install.
• Moved scripts functionality into its own module.
• Reference utility functions from _shutil.
• Remove easy_install and package_index.

Summary of changes

Closes

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[rmb938]

Hey @jaraco I think this broke openstack packages.

When trying to install them I am getting

AttributeError: module 'setuptools.command.easy_install' has no attribute 'sys_executable'

I did find your bug submission here https://bugs.launchpad.net/pbr/+bug/2107732 so I guess this is the reason... seems like PBR devs didn't do anything to mitigate this :(

[jaraco]

That bug report is meant to track the removal of develop and install commands and I only expect response to it in the order of months. Setuptools still maintains a (passing) pbr integration test to ensure that pbr works nominally (and this test protected against regressions in develop and install).

The sys_executable compatibility attribute was restored in Setuptools 12.0.1 11 years ago. I even found the commit where that property was removed (bd9d380), but there are no comments there.

I don't see that I ever added a deprecation warning or linked any ticket, so I'm not even sure how I learned about the issue or why I addressed it the way I did. Perhaps I was pinged in a private channel or in another bug tracker (the code was likely in Bitbucket at the time). Regardless, I can't find the rationale for exposing that attribute. In any case, the deprecation was mentioned there, so presumably someone at pbr knew this removal was pending.

If someone wants to make the case that this attribute should be restored and there should be a deprecation period, I'm willing to supply it for up to 6 months. Just have that project file an issue in Setuptools and tag me in on it.

[rmb938]

Interesting that the test still passes as a pip install -e . of https://github.com/openstack/neutron/tree/master for example fails since the sys_executable = CommandSpec._sys_executable() was removed from the easy_install file.

Must be something different going on then what your test covers 🤷

Anyway appreciate the reply, I'll wait to see what the pbr folks decide to do :)

[tiran]

I have reported the issue as #4976. Please yank setuptools 80.3.0 ASAP. Setuptools breaking major parts of the Python community again. In fact it is the fourth release with major breaking changes in since mid of March.

[Joshix-1]

It also broke installing hylang/hy#2653, people should really start pinning setuptools versions in pyproject.toml, but many don't even have that file.

[tiran]

It also broke installing hylang/hy#2653, people should really start pinning setuptools versions in pyproject.toml, but many don't even have that file.

That's not a good solution either. It's going to cause more trouble in the long run.

For starters setuptools development team has to reconsider their development style and must implement mandatory reviews and approval process. @jaraco has landed this major breaking change without any review or approval of other maintainers. All PRs should require at least one approval. Possibly breaking changes should require at least two approvals plus testing with major packages and build backends that rely on setuptools.

[Joshix-1]

Breaking changes should additionally be in a major versions. Then it would be enough to pin a major version. Currently I have to pin a patch version to guarantee that my stuff keeps working.
But yeah it would be better to not have to do that, but I don't see that happening.

[jaraco]

This change was meant to be non-breaking (hence the minor version bump). It was a follow-up change to the intended breaking change in v80 (#2908). I expected that change could cause disruption, so I wanted to implement it first and monitor for the fallout before fully removing the functionality in this PR.

I didn't expect this change to have significant impact given the minimal impact from #2908, but it's become clear that there is widespread dependence on internal APIs of Setuptools.

Maybe I should make it clear that any software that relies on undocumented functionality is unsupported and can break at any time, or maybe do something like pip did by moving everything into an _internal namespace. I'm really reluctant to do that, because it's inelegant and creates extra indirection.

[Joshix-1]

easy_install is still documented: https://setuptools.pypa.io/en/latest/deprecated/easy_install.html

[bsipocz]

I don't recall seeing a DeprecationWarning for this, thus it was a really big surprise to see the gazillion bug reports and failing CI run due to the removal of package_index.
I do use it in some legacy infrastructure that is due to be refactored, yet I was fully expected to be on top of any sudden and user-affected breakages by being on top of the deprecations. Is there any chance to revert that part of the PR, too in favour of a more gentle removal following a deprecation period?