[Distutils] RFC 2: PEP 541 - Package Index Name Retention

Donald Stufft donald at stufft.io
Tue Jan 17 13:01:46 EST 2017

> On Jan 17, 2017, at 12:25 PM, Chris Rose <offline at offby1.net> wrote:
> PyPi might not be an archaeological site, but like it or not it *is* a key part of deployment processes, including those that run headless. I'm referencing vendoring processes, but the same idea applies when your code is deployed by any process that includes `pip install` in its steps. While in an ideal world every user of these packages would host an internal mirror of the packages they need and rigorously vet them, that's not the world we live in.
> I raise the issue because I believe the bar for taking over an abandoned name should be nigh-insurmountably high; the risks are in my view severe, given the way software is built today.

If ~nobody is downloading it from PyPI today and ~nobody is releasing new versions to PyPI then re-using the name should have very little effect, even if in the past people had been using it. The only real use case I can think of where this might not be true is it could break someone’s ability to reproduce a deployment from many years ago but if you need to reproduce your build from years ago, depending on PyPI for that is not really the smartest bet. Otherwise it feels a lot like we’re in a “if a tree falls in the woods, but nobody is around to hear it does it make a sound?” territory.

One thing we could possibly do is provide the ability for, as part of the relqunishing process, “lock” the old versions that were uploaded so that the new owner can neither delete them or upload new files for them AND set a “minimum version” for new uploads for that project. This could mean that one could say that foobar < 4.0 is the old project and foobar >= 4.0 is the new project and existing == continue to work. I’m not sure I feel about that though.

Ultimately, consumers need to either live with these sorts of problems or they need to develop their own solutions for counteracting them (like vendoring) because while this proposed policy *could* cause them these issues, it’s not the only way for them to occur. Specifically, this only deals with cases that the original author is no longer responsive in some way, but fit hey are it’s typically not very hard in my experience to convince someone to give up a name they once used and are no longer interested in maintaining. I’ve acted as the middleman for this very arrangement on a number of occasions.

Donald Stufft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170117/b466a086/attachment.html>

More information about the Distutils-SIG mailing list