[Catalog-sig] disallowing the removal of packages?
faassen at startifact.com
Mon Jul 4 17:41:17 CEST 2011
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
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