[Catalog-sig] an immutable mirror of PyPI

[Jim Fulton]

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
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