[Catalog-sig] an immutable mirror of PyPI

[Alan Franzoni]

On Wed, Jul 6, 2011 at 11:10 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Some possible reasons:

>  * renaming packages (e.g. due to a poor initial package name
>   choice)

This is not a good reason, IMHO. You can go on with new versions and a
new name, maybe you could want to deprecate the old package, but it's
not a good reason to remove it.

>  * legal action (copyright, trademark, DMCA, license issues, etc)
>
>  * removal of malicious packages (e.g. script kiddy stuff in
>   setup.py)
>  * seriously broken builds (e.g. that cause users to lose data)

This is would make a good reason for package removal, but not for
version reassignment. I.E. if I delete version 0.4.3 because it
deleted my /usr instead of /usr/share/mylib/content, then I would be
right at removing it, but there's no point in allowing any other
package to take back 0.4.3. It's simply gone.


>  * reassigning package names (not sure whether that's possible with
>   PyPI, but it certainly happens in the wild every now and then)

I'm not sure about what you mean here.


BTW I think that the main issue here is *why* anybody should delete
anything from pypi. If your conditions above apply, it's perfectly
right for a dev to remove the packages. But I think most packages are
removed without such conditions.

Since I think such events are pretty rare, there could be a ticketing
system dedicated to an "emergency removal" of artifacts, and that
reupload of an artifact with the very same name-release should be
inhibited.

-- 
http://www.franzoni.eu - public@[mysurname].eu
Latest blog post: Unit testing with Twisted: testing protocols:
http://t.co/HFpslG4