[Python-Dev] People want CPAN :-)

Michael Sparks sparks.m at gmail.com
Tue Nov 10 02:12:13 CET 2009


[ I'm posting this comment in reply to seeing this thread:
    * http://thread.gmane.org/gmane.comp.python.distutils.devel/11359
Which has been reposted around - and I've read that thread. I lurk on
this list, in case anything comes up that I'd hope to be able to say
something useful to. I don't know if this will be, but that's my
reason for posting. If this is the wrong place, my apologies, I don't
sub to distutils-sig :-/ ]

On Sat, Nov 7, 2009 at 2:30 PM, ssteinerX at gmail.com <ssteinerx at gmail.com> wrote:
> On Nov 7, 2009, at 3:20 AM, Ben Finney wrote:
>
>> Guido van Rossum <guido at python.org> writes:
>>
>>> On Fri, Nov 6, 2009 at 2:52 PM, David Lyon <david.lyon at preisshare.net>
>>> wrote:
>>>>
[ lots of snippage ]
...
> All in all, I think this could be a big leap forward for the Python
> distribution ecosystem whether or not we eventually write the PyPan I wished
> for as a new Perl refugee.

Speaking as someone who left the perl world for the python world, many
years ago now, primarily due to working on one project, the thing I
really miss about Perl is CPAN. It's not the fact that you know you do
perl Makefile.PL && make && make test && make install. Nor the fact
that it's trivial to set up a skeleton package setup that makes that
work for you. It's not the fact that there's an installer than can
download & track dependencies.

The thing that makes the difference IMHO is two points:
    * In a language which has a core ethos "There's more than one way
to do it", packaging is the one place where there is one, and only one
obvious way to do it. (Oddly with python, with packaging this is
flipped - do I as a random project use distutils? pip? setuptools?
distribute? virtualenv?)
    * It has a managed namespace or perhaps better - a co-ordinated namespace.

CPAN may have lots of ills, and bad aspects about it (I've never
really trusted the auto installer due to seeing one too many people
having their perl installation as a whole upgraded due to a bug that
was squashed 6-8 years ago), but these two points are pretty much
killer.

All the other aspects like auto download, upload, dependency tracking,
auto doc extraction for the website etc, really follow from the
managed namespace really. I realise that various efforts like
easy_install & distribute & friends make that sort of step implicitly
- since there can only be one http://pypi.python.org/pypi/flibble .
But it's not quite the same - due to externally hosted packages.

For more detail about this aspect:
   * http://www.cpan.org/modules/04pause.html#namespace

I'm really mentioning this because I didn't see it listed, and I
really think that it's very easy to underestimate this aspect of CPAN.

IMHO, it is what matters the most about CPAN. The fact that they've
nabbed the CTAN idea of having an archive network for storing,
mirroring and grabbing stuff from is by comparison /almost/ irrelevant
IMHO. It is the sort of thing that leads to the DBI::DBD type stuff
that is being simple to use, because of the encouragement to talk and
share a namespace.

The biggest issue with this is retrofitting this to an existing world.

Personal opinion, I hope it's useful, and going back into lurk mode (I
hope :). If this annoys you, please just ignore it.


Michael.


More information about the Python-Dev mailing list