Working group for Python CPAN-equivalence?

[Olof Bjarnason]

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

I'm wondering - is there any work being done identifying ..

(1) what is so good with CPAN?
(2) how can it be brought to the Python world?

Is there a working group/initiative for this? Web page? Discussion group?


/Olof

 

[John Gabriele]

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

I'm wondering - is there any work being done identifying ..

(1) what is so good with CPAN?
(2) how can it be brought to the Python world?

Is there a working group/initiative for this? Web page? Discussion group?

Hi Olof,

Discussions about that often take place on the distutils-sig and
catalog-sig MLs.

People are currently working on making the Cheeseshop even better and
the situation is improving. Have a look at [Tarek's blog](http://
tarekziade.wordpress.com/) for more info.

---John

 

[John Nagle]

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.

CPAN is a repository. PyPi is an collection of links.

CPAN has over 260 mirrors. PyPi has none.

CPAN enforces standard organization on packages. PyPi does not.

CPAN has quality control, with testers and a test reporting system.
PyPi does not.

John Nagle

 

[Terry Reedy]

CPAN is a repository. PyPi is an collection of links.

As Ben said, PyPI currently is also a respository and not just links to
other repositories.

CPAN has over 260 mirrors. PyPi has none.

A mirroring system has been or is being set up with at least a couple of
mirrors for things that are hosted at PyPI.

CPAN enforces standard organization on packages. PyPi does not.

CPAN has quality control, with testers and a test reporting system.
PyPi does not.

People who are familiar with and like CPAN are free to help improve
PyPI. Those of us not familiar with it may not know what we are missing,
or have little idea about what works with CPAN.

Terry Jan Reedy

 

[Jonathan Gardner]

People who are familiar with and like CPAN are free to help improve PyPI.
Those of us not familiar with it may not know what we are missing, or have
little idea about what works with CPAN.

CPAN also covers up some deficiencies in Perl that Python doesn't
suffer from. I am sure we could do well not to replicate those
features.

Regardless, Python's packages are distributed in a number of ways.
PyPI is only one of them. Fedora and Ubuntu are two other ways.

 

[Philip Semanchuk]

CPAN also covers up some deficiencies in Perl that Python doesn't
suffer from. I am sure we could do well not to replicate those
features.

Regardless, Python's packages are distributed in a number of ways.
PyPI is only one of them. Fedora and Ubuntu are two other ways.

Do Fedora & Ubuntu's package managers offer modules that appear in
CPAN? In other words, if I was a Perl user under Ubuntu would I use
the pkg manager to add a Perl module, or CPAN, or would both work?


Thanks
Philip

 

[John Bokma]

Do Fedora & Ubuntu's package managers offer modules that appear in
CPAN?

Yes, I've installed so far all Perl modules I need that way (sudo
apt-get install ...)

In other words, if I was a Perl user under Ubuntu would I use
the pkg manager to add a Perl module, or CPAN, or would both work?

Both would work, but I would make very sure to use a separate
installation directory for modules installed via CPAN.

AFAIK there are also programs that pack CPAN modules/bundles into
something the package manager can use to install.

 

[Gregory Ewing]

A very important thing about CPAN modules is the consistent
basic install method: perl Makefile.PL ; make ; make install

Well, we more or less have that with Python, too:

python setup.py install

It may not always work smoothly, but it's the
one obvious thing to try when you've downloaded
a Python package in source form.

 

[Olof Bjarnason]

Well, we more or less have that with Python, too:

 python setup.py install

It may not always work smoothly, but it's the
one obvious thing to try when you've downloaded
a Python package in source form.

I want to say thanks to all that have given information regarding the
original question - for example the blog mention was valuable, aswell
as the disctintion between CPAN and cpan.

It was definately *not* my intention to start another "Where is CPAN
for Python?"-thread, but it seems we're already there.

 

[John Gabriele]

Both would work, but I would make very sure to use a separate
installation directory for modules installed via CPAN.

What's worked best for me is: use *only* the apt system to install
modules into your system Perl (`/usr/bin/perl`) and use *only* cpan/
cpanp/cpanm to install modules into *your own* Perl (for example, you
may have installed into `/opt`).

AFAIK there are also programs that pack CPAN modules/bundles into
something the package manager can use to install.

Right. If you really want to install a module for which there's no
Debian package, and you don't want to install your own Perl, this is a
good route to take.

Incidentally, this is the same way I recommend handling the situation
with Python: Use only aptitude to install packages for your system
Python, and use only pip to install packages into your own Python
(which you built and installed elsewhere, ex., `/opt/py-2.6.4`).

---John

 

[John Gabriele]

This is, I think, something we don't need as much in Python; there is a
fundamental difference between Perl's deeply nested namespace hierarchy
and Python's inherently flat hierarchy.

What do you think that difference is? Both use nested namespaces. My
understanding is that if 2 different dists contain like-named
packages, and if a user installs both of them, they all just go to the
same place in the user's site-packages dir.

One difference I see is that the CPAN has a *lot* of dist's which
constitute a very large number of modules. Keeping them organized by a
semi-agreed-upon hierarchy of packages seems like a great
organizational tool.

---John

 

[John Bokma]

As Ben said, PyPI currently is also a respository and not just links
to other repositories.

[..]

This is, I think, something we don't need as much in Python; there is a
fundamental difference between Perl's deeply nested namespace hierarchy
and Python's inherently flat hierarchy.

Perl's hierarchy is 2 (e.g. Text::Balanced) or 3 levels deep
(e.g. Text::Ngram::LanguageDetermine), rarely deeper
(Text::Editor::Vip::Buffer:lugins:isplay). Which is in general most
likely just one level deeper than Python. Perl is not Java.

And I think that one additional level (or more) is a /must/ when you
have 17,530 (at the time of writing) modules.

If Python wants it's own CPAN it might be a good first move to not have
modules named "xmlrpclib", "wave", "keyword", "zlib", etc. But I don't
see that happen soon .