[Catalog-sig] disallowing the removal of packages?

Martijn Faassen faassen at startifact.com
Mon Jul 4 22:49:19 CEST 2011


Hi there,

On Mon, Jul 4, 2011 at 10:39 PM, Laura Creighton <lac at openend.se> wrote:
> 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.

This would, I imagine, be an improvement. Anyway, it's not that this
is happening a *lot*; it's in fact extremely
rare. This is what makes it so tempting to use PyPI in the way I (and
many others) are using it. Perhaps with a warning like this it would
not happen at all anymore. But you can't rely on it.

> 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.

A communication channel for package maintainers to tell package users
"hey, this has a really serious security bug!" or "this is deprecated"
would be useful. The package homepage on PyPI can be used for that, of
course, though perhaps isn't perfect as people who are using your
package indirectly might not ever see it.

But even if we had a deprecation mechanism, it wouldn't exactly solve
my use case, as it'd still mean that I would need to distribute my own
backups of all packages I'm using to be able to reliably replicate an
installation somewhere else. Sometimes this is not a burden, and often
it's wise to do so anyway, but frequently (say with a bunch of
geographically distributed developers) it is a lot more convenient to
be able to rely on a central infrastructure. It's not like doing this
for dependencies is unheard of either - people are relying on content
distribution networks for Javascript dependencies, for instance.

Anyway, not changing or removing old releases just seems like the
Right Thing To Do in general in software development; I'd like the
tools to support this.

Regards,

Martijn


More information about the Catalog-SIG mailing list