On Mon, Dec 21, 2009 at 11:13:31AM +0100, Lennart Regebro wrote: > What nobody still fails to explain in this discussion is what CPAN > "is" and Why Python doesn't already have it. > There is just a lot of "CPAN is great!" And "Python needs CPAN" but > noone can come up with one single thing that CPAN does that Python > doens't have, or explain why CPAN is so great, where PyPI isn't. > > And unless somebody can do that, this discussion ain't going nowhere. :)
Here are a couple things I really like about CPAN: 1. Module documentation - the perldoc is extracted, formatted as HTML, and is available for browsing (e.g., search.cpan.org - perhaps this is part of the "sugar" described by Steffen but it tastes delicious). The same could presumably be done with pydoc. (Some modules have some documentation on PyPI, but it's not the pydoc, just a summary.) (The local pydoc server also doesn't help me for modules that I don't have installed yet, and installing every module matching, say, "ID3", and then reading the pydoc is a significant hurdle.) Slightly tangentially, the Python community doesn't seem to have instilled the same documentation culture as the Perl folk. The standard perldoc sections (DESCRIPTION, SYNOPSIS, etc.) are enormously helpful, whereas pydoc seems limited to very dry docstrings, and tends to import unneeded extras (e.g., when 'pydoc dbus' shows the dbus.Array class, it also feels a need to list all the methods of the __builtin__.list class from which it inherits). It's become more of a rule than an exception to have to examine the module source to determine how to use a Python module. 2. A conceptual link between different versions of the same module. On CPAN (search.cpan.org), there's a page for module X with a dropdown for the known versions and their release dates, which may also be downloaded. PyPI appears to treat multiple versions of the same package as completely different entries. A link to an extracted changelog is also convenient. 3. Index by module name (as well as package name). Even further, it would help predictability to make the two match when possible (as perl module X::Y version V will usually be X-Y-V.tar.gz), or at least obviate the need to display package names. Frequently I don't care about the cutesy package name, just what it implements. 4. Namespaces and some way of reserving them. There are likely many modules named postgresql on PyPI, but there's only one DBD::Pg (although there are other PostgreSQL modules that implement the perl DBI driver interface). This also helps with specifying dependencies. > A simple place where you can upload packages? Check. > An index of those packages? Check. > Loads of sugar on top? Check. OK, one drawback there is that Python > has sugar on top of the sugar, and slightly competing sugar, and it's > difficult to know which type of sucrose to use. But that is being > worked on. If Python has the listed items - if they're in the "sugar on top of the sugar" - I apologize, and please point me to them, since I've had a hard time finding them. I don't think competition hurts, either (search.cpan.org vs. kobesearch.cpan.org). > So... what? If Python needs CPAN, then what is CPAN? Because as far as > I can tell, Python has CPAN, and has had it for years. It definitely appears to have the framework, but lacks some finishing touches that would enormously enhance usability. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
