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

"Martin v. Löwis" martin at v.loewis.de
Sat Dec 26 12:22:01 CET 2009

> Sorry, but I'm not being philosophical when I say you have to authorize access
> to things. Apparently the Python repository does, too. Or otherwise I'll upload
> a few popular packages with high version numbers that contain viruses for New
> Year.

Maybe it's a terminology matter. "I" have to "authorize": who is "I"?
In PyPI, no person ever authorizes access. Yet, you still cannot upload
newer versions of popular packages.

Package names are registered on a first-come first-served basis. You
could register a popular package if you were the first one to do so.
However, all the popular packages are already registered, and then only
the person originally performing the registration may upload newer
versions (strictly speaking, that person can also delegate that
permission to others, but that is besides the point that the archive
operators will never need to authorize anything).

> Now, on CPAN, I *can* upload anything even if not authorized to do so. It just
> won't be part of the official indexes if I upload a new version of the database
> interface DBI.

In PyPI, you can upload the popular package under a different name. It
will be indexed and all, but people still may not use it because of the
different name.

> That we do out meta data stuff on package/namespace/class names as opposed to
> distribution names has the huge benefit of interoperability between
> distributions.

I think you misunderstood the Python term "distribution" here (or I
misunderstand the point you make). A "distribution" is a tar file (or
such); it's what library authors distribute. There can't be
"interoperability" between them, at least not in the way I understand

>>> Think about it like this: If you install any module from CPAN (and
>>> only the valid ones end up in the index), you can use all of them in
>>> the same application. If module A and B could both implement
>>> Config::Parser, then you couldn't use both of them at the same time.
>> This would be true for Python too. But Python doesn't try to pretend
>> that all the packages that exist are some sort of standard library,
>> and therefore don't try to put them all into one sort of hierarchical
>> organized namespace. And to be honest I don't see the point of doing
>> that.
> We're not pretending anything. We're not forcing anything except that you don't
> override somebody elses work.

I think the point here was that "we" see the advantage that CPAN imposes
with the namespace registrations primarily as theoretical. Yes, it does
prevent two people putting code into Config::Parser, and yes, in theory,
it may be that they do the same in Python with PyPI. In practice, that
is never a problem - there are so many names to chose from, and if you
do happen to conflict with somebody else's naming choice, AND there is
indeed interest in using both packages simultaneously, your users will
ask you to rename your package. However, that happens so rarely if at
all that it hasn't been a real concern.

>> And obviously on PyPI, it's first come first serve as well. But nobody
>> would call a db package "db" if one already exists. Why would they do
>> that? What's the point? Why would I make a completely new package
>> called "Twisted" for example? There already is one. It's just a
>> mindset that is completely incomprehensible to me.
> Then you clearly do not understand what it is like to be
> a) malicious
> b) new, young, inexperienced
> c) stupid.

If you have malicious users, and unsuspecting users download and run
their code, no namespacing mechanism can stop them, neither in CPAN nor
in PyPI. Malicious users would be able to bypass any checks that are
performed, and experienced users, code review etc. needs to discover

New or stupid users may accidentally create colliding names. However,
in Python, packages aren't called "db", but, say, "psycopg2", "Twisted",
"django", or "zope". Chances are fairly low that new users accidentally
come up with such a name.


More information about the Distutils-SIG mailing list