[Catalog-sig] disallowing the removal of packages?

[Andreas Jung]

Martijn Faassen 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.

First I have to second Martijn in all aspects (bascially because
are coming from the same projects and facing similar problems).

The main (meta) question is: is PyPI a the wild-west of the Python world
where everyone can do with packages or do we want PyPI being a 
well-managed place for packages with a certain number of rules. Looking 
at the RSS feed each day makes me angry sometimes because PyPI feels 
like the dumpster of the Python world. The points Martijn raised are 
only one aspect of this question.

-aj

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 310 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20110705/a847a459/attachment.vcf>