[Catalog-sig] an immutable mirror of PyPI
faassen at startifact.com
Tue Jul 5 17:34:38 CEST 2011
On 07/05/2011 04:51 PM, P.J. Eby wrote:
> At 04:18 PM 7/5/2011 +0200, Martijn Faassen wrote:
>> That's why I asked
>> whether PyPI is primarily a hosting site for developers (as opposed to
>> something like Debian or Wikipedia which have notions about a
>> collaborative effort of some kind, and care about preserving history).
> It's right there in the name: Python Package *Index*. In other words,
> it's an index of packages. Hosting the packages is optional. Heck, a
> package actually having any *code* to download at all is optional, since
> you can list a package you merely intend to develop. Or you might just
> have a revision control link, etc.
Something being an index doesn't necessarily imply that the index will
behave in a certain way. For instance, if I have an index of a database
table I rather expect that things mentioned in the index actually are
kept in sync with things in the database table. It depends entirely on
what kind of index it is trying to be.
If PyPI's index followed some principles of immutability it could be
used in different ways than if it isn't.
> So no, it's not a curated repository of code. If that were the case,
> it'd be better named the Python Code Repository or some such.
Sure, if it turns out that is a more useful to people, it might be
changed (given certain assumptions about what the word "index" applies)
> The perspective that you have is influenced by your use case for PyPI;
> by nature, these other sorts of packages (i.e. ones without uploaded,
> released code) are ones you don't care about. But that doesn't mean they
> don't exist.
I'm not saying that my use case is the only use case for PyPI. I just
submitted my use cases for discussion. This is why I was carefully
analyzing use cases for package removal in the first place... I'm still
missing a few, but people don't seem to want to share them. :)
> In any case, you can't turn PyPI into PyCR by the simple expedient of
> disallowing deletions; you'd need actual curators and a fresh website
> that doesn't contain all the unreleased, unmaintained, un-existent, or
> un-open-source packages found on PyPI.
I think you misunderstand: I am the curator of my own list packages and
versions. I just like using a shared central system by which those
packages are shared (and many others I might want someday to add to my
Using the existing PyPI repository for this works fairly well, but there
are some issues, such as package changes and package removal. I thought
that since others might have similar concerns, we could work together to
offer some guarantees that would help external curators such as myself.
It appears however that my use cases are not shared by most people
responding in this thread. That doesn't mean that they're necessarily
invalid use cases for PyPI, but I'm not holding out much hope after this
More information about the Catalog-SIG