[Catalog-sig] disallowing the removal of packages?

Jim Fulton jim at zope.com
Mon Jul 4 19:04:49 CEST 2011

On Mon, Jul 4, 2011 at 11:41 AM, Martijn Faassen <faassen at startifact.com> wrote:
> 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?



Jim Fulton

More information about the Catalog-SIG mailing list