[Catalog-sig] an immutable mirror of PyPI

[Martijn Faassen]

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 
list).

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 
reception. :)

Regards,

Martijn