[Catalog-sig] an immutable mirror of PyPI
jim at zope.com
Tue Jul 5 15:52:37 CEST 2011
On Tue, Jul 5, 2011 at 8:12 AM, M.-A. Lemburg <mal at egenix.com> 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
- 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
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
More information about the Catalog-SIG