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

[Lennart Regebro]

On Mon, Dec 21, 2009 at 12:42, David Robins <python at davidrobins.net> wrote:
> 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.)

Interesting. I generally don't find automatically generated
documentation useful, but if it works for PERL I guess that's a
personal taste.

There is a place for module documentation now, but it's not
automatically extracted, but a place for any sort of documentation. An
example: http://packages.python.org/distribute

A site that automatically generated pydoc documentation for all
modules on PyPI should be possible.

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

All "visible" versions are listed on PyPI, it's just that the default
setting is to hide old versions by default.
I agree that a "show old versions" link could be a good idea there.

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

It's very unusual that these differs in my experience. On the top of
my head I can think of two: python-dateutils and Plone, which you use
with "import dateutils" and "import Products.CMFPlone" respectively.
In the Plone case there is a good reason. :)

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

There is no reserving in the Python world, that's true. I'm skeptical.
There's enough problems with packages not being updated, we don't want
that for namespaces too, that would be terrible.

> It definitely appears to have the framework, but lacks some finishing
> touches that would enormously enhance usability.

So far we have identified a "show all versions" link, and
automatically generated documentation. Thanks! Finally something
concrete! :-)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64