[Catalog-sig] an immutable mirror of PyPI
mailing at franzoni.eu
Wed Jul 6 16:20:52 CEST 2011
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
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
> * 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
http://www.franzoni.eu - public@[mysurname].eu
Latest blog post: Unit testing with Twisted: testing protocols:
More information about the Catalog-SIG