Restore and slow remove package index

[jaraco]

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?

Originally posted by @bsipocz in #4963 (comment)

[jaraco]

I was under the impression that package index was an internal implementation detail of easy install. This is the first I'm learning of this public use.

We could consider restoring it, especially if the impact is significant. Since you are possibly the only affected user, I'd like to consider other options.

How difficult would it be in your legacy services to pin to Setuptools<80?

[bsipocz]

The library is not legacy, but quite widely used, it's just its infrastructure that is dated. However, it was built with a now deprecated package template, so I expect other things are also using the same infrastructure (and indeed, there are quite a lot many finds on github, though I expect most of these are obsolete).

So while I fixed astroquery's main, I would still consider it to be a nice thing to make this removal a slower process, e.g. not breaking building from source for our last releases

[jaraco]

I would still consider it to be a nice thing to make this removal a slower process.

I agree, and that's the usual expectation.

I can see in #2110 and #2823, I was exploring removing package_index, but never got as far as marking it as deprecated in the code, in part because the plan to provide a replacement was stalled by a PyPI squatter.

I respect that users come to the table with the presumption that any non-underscore-prefixed names are fair game to rely upon. In Setuptools, that hasn't been the case for some time. This project has had the stated intention to be a build backend and nothing more. I'm working hard to set that expectation in efforts such as #4978.

But given that it's been removed and there's been little outcry, I'm hesitant to bring it back for little or no value.

I fixed astroquery's main

I'm not familiar with astroquery or the infrastructure you allude to, but I'm glad to hear that it was a (presumably) easy fix.

Given this fix is in place, what's the ongoing impact? If there is ongoing impact, is it possible to mitigate the breakage by pinning Setuptools?

I'm committed to revert the change if it's worthwhile, but I don't want to adopt the burden if it's just a formality. The effort (restoring the behavior, marking it as deprecated, cutting a release, then waiting 6 months to undo all of that, addressing any security issues in that code in the meantime) is a lot of work on a project that's already laden with tech debt (distutils adoption, pkg_resources removal, etc). If the effort to retain the compatibility is greater than the (collective) effort to adapt downstream, then I want to avoid that, even if it does defy reasonable conventions.

[gotcha]

Throwing a naive question: would it be hard to extract the code as a separate setuptools.package_index package ?

[jaraco]

Throwing a naive question: would it be hard to extract the code as a separate setuptools.package_index package ?

My guess is probably not, though I haven't looked into it. It probably would still have a dependency on Setuptools, which would mean the package would start out deprecated, but if someone wishes to do that as a temporary band-aid, I'd endorse it for the short term (order of months).

Since there hasn't been any response regarding the impact, I'm going to assume the impact is now negligible, so I'm closing this issue, but I can revisit it if anyone wishes to follow up with a compelling case.

[gotcha]

It probably would still have a dependency on Setuptools, which would mean the package would start out deprecated...

@jaraco, Can you explain what you mean by "starting deprecated" ?

Did I miss anything outside https://packaging.python.org/en/latest/discussions/setup-py-deprecated/ ?