[Catalog-sig] disallowing the removal of packages?

[Jim Fulton]

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?

+1

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton