> 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 "interoperability". >>> 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 that. 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. Regards, Martin _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
