Another thing that arises with yanking is the idea of deprecating releases or packages.
While in many cases yanking is sufficient, it's nice to have a way to explicitly deprecate rather than yank packages that are e.g. no longer maintained, have been renamed, or have better replacements, without necessarily cutting a new release (as that may not inform existing users). I've done so for my packages before by editing the package description and replacing it with a deprecation notice. On Tue, Dec 19, 2017 at 4:46 PM Donald Stufft <don...@stufft.io> wrote: > > On Dec 19, 2017, at 4:30 PM, Matthias Bussonnier < > bussonniermatth...@gmail.com> wrote: > > One alternative is have the ability to "yank" a package. Make it still > available, but installable only when pinned explicitly. I believe that's > what Rust does. > > > The ability to yank a package is something I’d love to introduce, > unfortunately it will require changes to the API that tools like pip use, > because PyPI does not currently have any idea why you’re asking for a list > of the releases, just that you’re asking for one. We’d also want to do it > in a way that doesn’t introduce unnecessary overhead in terms of HTTP > requests or caching (for instance, previously pip would look up > /simple/foo/2.0/ if you did ``pip install foo==2.0`` but we removed that > because in 99% of cases it wasn’t going to be more helpful than just > requesting /simple/foo/ and it made it harder to cache our pages I Fastly > for everything). > > One possible solution is to simply add a ``data-yanked=true`` field on > /simple/foo/. That would mean that much like requires-python you’d need to > have a new enough pip to support yanked packages properly but it wouldn’t > destroy our cacheability like the old method did. This wouldn’t require any > real changes to any of the mirroring tooling and static mirrors would still > be totally feature complete. > > Another possible option is to just exclude the yanked listing by default, > but have something like ?yanked=true added to the URL which would then > include *all* the yanked releases. This is “safe” to do in the case of ==, > because adding extraneous yanked releases isn’t going to matter, since the > == will only allow it to install one of them anyways. It bloats our cache a > bit (two versions of the /simple/<foo>/ url for each project instead of 1) > but it doesn’t completely destroy it like the /simple/foo/<version>/ scheme > did. This option would mean that older versions of tools simply wouldn’t > see the yanked versions ever, even with ==. It also would probably preclude > the ability to have a fully static mirror, since you’d need something to > handle the ?yanked=true handling (although we could maybe get around that > by using something like /simple/_yanked/foo/ or something). > > There are possibly other ideas to handle this that I’m not thinking of > offhand, but I think fundamentally the question will come down to whether > we want older versions of the tooling to see yanked packages by default or > not. > > Ultimately this is probably a big enough feature that it would deserve a > PEP to flesh out the various options and to figure out which path we go > down. Unfortunately I don’t currently have time to handle that, but would > gladly participate in such a discussion if someone were to lead it. > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
