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

[Jacob Kaplan-Moss]

On Tue, Apr 19, 2011 at 11:11 AM, Éric Araujo <merwok at netwok.org> wrote:
> BTW, what is Python Packages?  I’ve looked at Django Packages and it
> looks like a project index, like PyPI, so I wonder what Python Packages
> is that PyPI isn’t (or couldn’t be patched to be).

I can't speak for Danny's motivation behind Python/Django Packages,
but I can give you some insights into why Django Packages has been
valuable for our community. Hopefully that can answer your questions a
bit:

We've been really lucky to have a awesome community of third-party
Django apps, but today we've got a classic paradox of choice problem.
PyPI lists about 1,100 Django packages! This is clearly a good thing,
but it's also a problem: it's hard to figure out what to use for any
particular need. PyPI's got a bit of an interface for browsing these
packages (http://pypi.python.org/pypi?:action=browse&c=523), and
there's a search engine, but you still end up with a big choice
problem. If I search for "django media" on PyPI, I find dozens of
packages that can handle my media-file needs... but should I use
django-mediafiles or django-staticmedia or django-fresh-media or...

The key insight that (for me) makes Django Packages useful is that it
*groups* related packages together and lets me see, at a glance, which
of a set of related packages is the most useful. So I can visit
http://djangopackages.com/grids/g/asset-managers/ and discover that
django-staticfiles, while the most popular (by an "I use this" count)
doesn't support, say, JavaScript compression. If that's a feature I
need, then I can use that package.

I've started pointing people to grids (groups of packages) on Django
Packages because they're living documents that describe all the
solutions in a given problem space. I don't have to worry about my
advice getting out of date, and I don't have to force my choices onto
people. I can simply point them to the comparison pages and let them
draw their own conclusions.

Again speaking strictly as a user, I would *love* this to exist for
the greater Python ecosystem. I would really like to point someone to
http://pythonpackages.com/grids/g/xml-processors/ when helping them
decide between an XML engine. Or a web framework, for that matter!

Perhaps this could be part of some future PyPI. However, I see two
reasons why it probably won't:

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

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

To sum up, I'm incredibly happy with Django Packages, and that's why
I'm waiting anxiously for Python Packages to launch (and why I'm
helping make it happen).

Jacob