Olof Bjarnason <olof.bjarna...@gmail.com> writes: > Hi everybody! > > The "Where is CPAN for Python?" question keeps popping up, with > answers ranging from "There is no CPAN for Python" and "We already > have CPAN for Python" (confusing).
Caused in no small measure by the fact that Perl people mean at least two distinct things by “Where is CPAN for Python?”: * The central package registry, CPAN, with metadata in a standard queryable format, and all registered packages redundantly mirrored and available for installation at user-specified versions. We have an equivalent in PyPI, though it's incomplete since many *registered* packages are not actually hosted *at* PyPI. * The command-line tool, ‘cpan’, used for performing operations on the set of locally-installed Perl packages, and for package maintainers performing operations on the repository. We have nothing like this. The Distutils library does a small part of the job, and the third-party ‘easy_install’ program works for those which use the Setuptools extensions; but there's nothing at all equivalent to Perl's ‘cpan’ tool. Often, Perl people asking simply “Where is CPAN for Python?” are asking about a third thing: * The unified, mature, actively-maintained, seamless combination of the CPAN repository and the ‘cpan’ tool, that work together as a single reliable system to such an extent that one can sensibly talk about them *both* as one thing, “CPAN”. This one we're a *long* way from with Python, IMO. Much work has been going on over the last year or so, and it's encouraging to see; but so much of that work is dealing with the legacy burden of Distutils that I get weary seeing how far there is to go. -- \ “A child of five could understand this. Fetch me a child of | `\ five.” —Groucho Marx | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
