On Tue, Jul 5, 2011 at 8:12 AM, M.-A. Lemburg <[email protected]> wrote: ... >> PyPI just is at this point where it works 99.99% percent of the time, >> but it allows sudden surprises to pop up. > > I think that's just a coincident, not really a feature :-)
Actually, it's not. Within the Zope community, we early on realized the value of PyPI and setuptools as a collaboration tool and also realized that to fully realize it's potential, we'd need a policy of not removing old releases from PyPI. This policy was promulgated within the Zope community, has been followed, and has proven valuable. Of course, we still get burned from time to time when old versions of other packages we use disappear. I really don't intend to get embroiled in this debate, I've already offered a +1 to Martijn's proposal, but I will additionally offer a some opinions: - IMO, PyPI should be more for package consumers than for producers. I really have trouble fathoming the idea that a package index/catalog of primarily for producers. Perhaps I'm being dense. - A lot of PyPI's value is as a collaboration tool. It's presense, and more so with setuptools and its spawn, has made dynamic application assembly possible and reuse far more practical. - While I endorsed Martijn's idea, I think a voluntary system would be just as good and probably more palatable. I don't think we need a depracation system. There's rarely a good reason to remove an old package. Old releases are hidden from the human interface and automated tools will pick new releases unless told otherwise. I think if people understood that people were relying on old releases, they wouldn't remove them. IMO, it would be enough to warn someone about to delete that someone might be depending on the release and that deleting it could cause them hassle. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
