[Catalog-sig] Catalog-SIG Digest, Vol 86, Issue 32

[Daniel Greenfeld]

Date: Wed, 20 Apr 2011 10:03:02 +1000
From: Richard Jones <richard at python.org>
To: Jacob Kaplan-Moss <jacob at jacobian.org>
Cc: catalog-sig <catalog-sig at python.org>
Subject: Re: [Catalog-sig] How about a dedicated web service mirror?
Message-ID: <BANLkTikQeGvqaq5Y9Qgw71RxxJMkHOcf-g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

>As the guy who wrote that hand-rolled WSGI app in the first place
>(back when Zope was really the only thing around) I've said a number
>of times that I'd love for the code to be modernised. I was even
l>ooking forward to making a start on it at the US PyCon sprints this
>year, but alas my employer couldn't fund my attendance. Packaginator
>sounds like it could have been a viable replacement. But they're going
>their own way, like so many other projects that have anything to do
>with PyPI.

The three big reasons why we never added PyPI like capability to
Django/Python Packages (now Packaginator) were:

1. A lot of people we respect said it would be best to support PyPI by
providing accessory functionality rather than replacing it.

2. Adding package handling components to the project would take more
time then we had to contribute to the project.

3. At PyCon people from various other groups (Plone, Pyramid, Fedora,
Ubuntu, Vim) wanted to use it for their own needs.

4. We never wanted to be in the hotseat for when our package system went down.

>> * Socially, Python Packages, like all community-generated content,
>> will always be a bit of a flawed product. Since the data there is
>> mostly human-driven, it's never going to be comprehensive, complete,
>> or accurate. Again taking the Django asset manager grid as an example,
>> I can see at least two things that are missing there.

Jacob, why haven't you added them?

:-)

>> This doesn't bother me as a user of Django Packages -- just as the
>> parallel issue doesn't bother me as a user of Wikipedia. But I would
>> *not* want to make Django Packages part of Django's official web
>> presence because that would imply an authority of the results that
>> could never actually be matched. As a community project, Python
>> Packages can avoid the political problems making it part of PyPI would
>> entail. No endorsements are needed or implied.

Yup. We are happy to give up the data to the DSF wants at any time but
I'm so very glad we never pursued DSF funding and that they've been
hands-off.

> And let's not downplay this. PyPI will gain no fancy new
> user-generated content features because Martin and I both know that
> someone, somewhere will complain and we'll get a load of crap for it.

We are actually worried about Python Packages in this regard.

Which is why we locked down the grid permissions system for when we
launch that project. The grids and packages will be moderated by
formal moderators, but Package owners can edit content related to
their own work.

Also, all the Packaginator metadata fields are based off of hard
metrics. There is no rating system on the project. The only thing that
shows up in metadata displays that is directly user-entered is a
single boolean of whether or not you use a particular package.

> A separate project on a separate website has no such fears. So we'll
> just focus on the core stuff and hope that we can provide useful
> services to those websites.

We really appreciate the hard work you've put into PyPI.

PyPI, being what it is, provides an absolutely critical service to the
Python community. Hosting packages is hard work and should be the
ultimate focus of the project. Everything else (docs, evaluations,
commentary) distracts from that focus.

> Here's hoping that Packaginator really takes off and we can get some
> really cool extra data around PyPI packages to help end developers
> out. And maybe there could be some kernel in there that we might adapt
> to become the new PyPI implementation...

Indeed. Lets see how things play out.

Daniel Greenfeld