On Tue, Apr 19, 2011 at 11:11 AM, Éric Araujo <[email protected]> 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 _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
