[Catalog-sig] disallowing the removal of packages?

Martijn Faassen faassen at startifact.com
Mon Jul 4 17:41:17 CEST 2011

Hi there,

My development project relied on a certain version of a package that is 
hosted on pypi. Unfortunately the package mainatainer had decided that 
certain older versions of the package were not longer supported and had 
removed them from PyPI altogether.

This broke the build procedure for my project: I had carefully pinned 
down that I wanted this version (as that's what we tested with), and it 
wasn't available anymore.

So, the removal of old packages from PyPI means that other people who 
rely on these packages with their installation instructions ("install 
Foo 3.3") or build tools (installation instructions, automated), 
suddenly have to deal with breakage.

I thought perhaps PyPI can help and handle this problem at the source.

What are the possible use cases for removing a release from PyPI?

a) mistakes: the upload was accidental - we weren't supposed to release 
this at all! I.e. I uploaded private code that I never meant to 
distribute in the first place.

b) actively hostile: the upload actually contains deliberately malicious 
code and protecting people against this *should* break their builds

c) legal issues: some party claims that this code is not PyPI's to 
distribute in the first place, and for legal issues it'd need to be 
taken down.

d) broken: security or other bugs that makes us want to loudly say, this 
is so broken, don't use it anymore

e) cleaning up old stale unsupported stuff.

I'd argue d) and e) are not up to the package maintainer to decide but 
to the person who integrates this package into their system. The person 
who integrates the package is the one who will need to make the judgment 
call to continue to use old unsupported or broken stuff. Integrators 
should be allowed to make such decisions in their own time at their own 
convenience; the package developer shouldn't be able to force such 
decisions by removing an old release.

(We can think about better warning mechanisms: perhaps there could be 
some metadata or rule to decide when an old release is "deprecated" and 
then integration and installation tools could warn about this, but all 
this would be to help the integrator a better decision on what to do.)

Use cases a), b) and c) are left. I think b) and c) should be handled by 
the PyPI administrators: this takes a judgment call and the package 
maintainer might not be involved in this at all.

Use case a) is the tricky one. I could upload something by mistake, and 
then immediately discover it and decide to throw it out again. But I'd 
be fine if I weren't allowed removing a release anymore after a period 
of a month. It could be that I only discover my mistake after a month, 
when people have already started relying on this version, but in that 
case as a PyPI user I'd want the administrators to issue a judgement 
call there too.

So, my proposal would be to allow people to remove a recent release 
freely, but after a period of (I don't know? A day? A week? A month?) 
removing the old release is not allowed anymore.

What do people think?



More information about the Catalog-SIG mailing list