[Catalog-sig] How about a dedicated web service mirror?

[Richard Jones]

On Wed, Apr 20, 2011 at 6:36 AM, Jacob Kaplan-Moss <jacob at jacobian.org> wrote:
> * Technically, the fact that PyPI's written as a hand-rolled WSGI app
> limits the number of people who're going to want to contribute.
> Packaginator (the code behind * Packages) lists 32 contributors
> already. Would those people have learned the PyPI codebase? I doubt
> it. I certainly am a hell of a lot more likely to contribute to a
> project written in Django, or Flask, or Pylons, or Pryamid than one
> where I have to take time re-learn a bunch of boring stuff like
> templates and db abstractions.
>
> With apologies to Aaron Sorkin, If Packaginator could have been part
> of PyPI, it would be part of PyPI.

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


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

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

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


     Richard