[Catalog-sig] disallowing the removal of packages?

P.J. Eby pje at telecommunity.com
Tue Jul 5 02:18:31 CEST 2011


At 10:39 PM 7/4/2011 +0200, Laura Creighton wrote:
>Idea:
>
>When somebody wants to remove a package, they get a message
>'are you sure you want to do this?  Other people may be relying
>on this package.  Wouldn't it be kinder to them to give them
>a depreciation period?'  And then, either kick in a depreciation
>period -- during which time if Martijn dl the package e gets told
>that it is deprecated, and is going away in XXX (reasonable time to
>be worked out later, for the purposes of this article, say 6 weeks).
>Then in 6 weeks the package automatically goes away.  Or if the
>author says, "Hell yes, delete the thing now!" than that happens
>instead.

This would be nice if there were a way to communicate to automated 
installation tools about this deprecation, in such a way that it 
reached people who could do something about it...  and somehow 
magically motivated them to act.

In practice, such a message would be mostly ignored by users until it 
actually broke their builds, at which time they will actually pay 
attention to what it says on the PyPI page.

(Or, more likely, they will complain to somebody upstream of them who 
will then look at the PyPI page.)

To put it another way, if you are removing a package because you 
really don't want people using it unless they have an excellent and 
*considered* reason for doing so (e.g. a version with security 
issues), you're not going to get anybody to STOP using that version 
unless you break their mindless automated build.  That's the only way 
you're going to get their (motivated) attention pointed at whatever 
needs changing.

That doesn't mean deprecation isn't a good idea, though.  Certainly, 
the build tools out there could be updated to flag warnings about 
deprecated packages, and people with projects big enough to have QA 
(i.e., the folks who most likely care about this issue anyway) 
probably WOULD pay attention to deprecation warnings.

(I don't think I'd object to using a deprecation process as the 
normal way of removing a package, but on principle I believe an 
author should have the ability to remove their uploads for any reason 
or no reason.)



More information about the Catalog-SIG mailing list