Python needs a CPyAN

[Stephen Ferg]

I am a very satisfied user of Python and have been for number of
years.  I would never willing use another language.  I wish all good
things for Python, and that moves me to express some thoughts about
Python's future prospects.

I submit that the future expansion of Python usage is constrained by
Python's lack of a CPAN-like facility, and I submit that without a
CPyAN Python will never even get close to achieving the degree of
widespread usage that Perl currently enjoys.

In saying this, I am not faulting Python's "batteries included"
philosophy or the standard library.  The standard library is one of
Python's greatest strengths.  The standard library is Python's "jewel
in the crown" and I whole-heartedly endorse Andrew Kuchling's recent
proposal that we focus our energies on improving it.

But there are limits to a standard library.  You can't put
_everything_ into a standard library, nor would you want to.  There
will always be many specialized modules that shouldn't be put into a
standard library, with new modules being developed all the time.

These not-in-the-standard-library modules -- let's call them external
modules -- are the keys to a language's growth, its popularity, and
ultimately its long-term survival.  The better the support for
external modules is, the more actively that they will be used and
(more importantly) re-used.  If external module support is good, that
makes it easy for developers to create external modules built on top
of existing external modules, and then to create even higher-level
external modules built on those, until a very large archive of very
powerful external modules is created.  With such an archive of
external modules, it is possible to do very complex, very specialized
tasks with only a few lines of code.

Note that the key to success is not the size of the archive.  CPAN is
not a success because it is large.  Rather, it is large because it is
a success.  CPAN is only secondarily a collection of modules. 
Primarily, CPAN is a set of *capabilities*: capabilities for storing,
documenting, checking for updates, searching, downloading, testing,
and installing external modules.  It includes support for creating
module tests and documentation.  And it is a social organization --
the CPAN testers group -- that guarantees at least a minimal level of
quality assurance for (and therefore trust in) modules in CPAN.  CPAN
(the library) is large because CPAN (the external module support
mechanism) is powerful and easy to use.

It is no good saying that Python doesn't need a CPyAN because we've
got Google, or we've got SourceForge, or we've got PyPI or distutils
or the Vaults of Parnassus.  Even used together, all of these tools
still fall short of the capabilities of CPAN.  Only a full CPyAN will
provide the quality and ease-of-use of external modules that will
enable Python to flourish in the coming decade.

This is _not_ to say that Python will die without a CPyAN.  It will
certainly survive and thrive.  But it will remain a niche language. 
Without a CPyAN, Python usage and the Python community can never and
will never grow to a size that even comes close to rivalling the size
of Perl.

Some might object that Python is not in a race with Perl, or that
popularity and size shouldn't be goals: that smaller and better should
be our goal.  But I submit that popularity _is_ a goal.  Ask any
Python programmer what his (or her) first wish is, and you will get
the reply: "I wish I could have a job in which I could spend all of my
time (or even, _some_ of my time) programming in Python."  The only
answer to that wish is popularity; such jobs won't exist until Python
becomes more popular.  (The second wish is an altruistic, professional
one: "I wish I could convince my organization to use Python, because
Python really is a better technology, and my organization really does
need it."  And the answer to that wish, too, lies in making Python
more popular.)

To those who treasure the standard library, and who switched to Python
to escape the need to visit CPAN for even trivial things, we can say:
that won't change.  The standard library will remain as strong as
ever; CPyAN will supplement but not replace it.

To those who shrink in revulsion from everything Perlish, I say:  CPAN
is a great system, regardless of who invented it.  It is the best
thing about Perl.  In the great tradition of Python eclecticism, let's
steal it!

Because a CPyAN is key to the long-term growth of Python, creating a
CPyAN should be one of the highest -- perhaps THE highest -- of the
Python Software Foundation's priorities.  Therefore, I would like to
suggest that the Python Software Foundation issue an RFP (request for
proposal) specifically for proposals to start building a CPyAN.

Building a CPyAN will be a big job, no question.  But I think that for
the Python community and for the Python Software Foundation, it should
be job number one.

-- Stephen Ferg (steve at ferg.org)

REFERENCES:

a very informative post on CPAN by Sean Reifschneider
http://groups.google.com/groups?hl=en&lr=&c2coff=1&selm=mailman.983354412.22606.python-list%40python.org&rnum=6

a post by Hans Nowak
http://groups.google.com/groups?hl=en&lr=&c2coff=1&threadm=39D0B743.A60%40hvision.nl&rnum=8&prev=/groups%3Fq%3D%2522something%2Blike%2BCPAN%2522%26hl%3Den%26lr%3D%26group%3Dcomp.lang.python.*%26c2coff%3D1%26selm%3D39D0B743.A60%2540hvision.nl%26rnum%3D8

google c.l.p for "something like CPAN"
http://groups.google.com/groups?q=%22something+like+CPAN%22&hl=en&lr=&group=comp.lang.python.*&c2coff=1&scoring=d

requirements for the catalog SIG
http://www.python.org/sigs/catalog-sig/requirements.html