[Distutils] Python people want CPAN and how the latter came about

David Robins python at davidrobins.net
Mon Dec 21 12:42:47 CET 2009


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.


More information about the Distutils-SIG mailing list