Restore and slow remove package index #4983
Comments
|
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? |
|
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 |
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'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. |
|
Throwing a naive question: would it be hard to extract the code as a separate |
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)
The text was updated successfully, but these errors were encountered: