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

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

Reply via email to