On Mon, Jul 4, 2011 at 11:41 AM, Martijn Faassen <[email protected]> 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 _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
