[Distutils] [Catalog-sig] Specification for package indexes?

Phillip J. Eby pje at telecommunity.com
Fri Jul 7 20:02:43 CEST 2006

At 03:01 AM 7/8/2006 +1000, richardjones at optusnet.com.au wrote:
>And I will mention again that I'm not willing to just whack this code into 
>the package index without some thought to to ramifications given that 
>distutils has no such name mangling or limitation.

...which is arguably a serious bug in the distutils.  Actually, it's 
several bugs having to do with inconsistent filename mangling throughout 
the distutils' various commands, and a design limitation of not 
anticipating that people would register Python packages with name's like 
"Bob's Incredible Package for Python".  :)

The ramifications of adding a fallback search to URL lookup (and you need 
*only* add it to URL lookup for "/pypi/projectname") are these:

1. Exact matches will work exactly as they do now
2. URLs that now produce "Not Found" would produce a list of links that 
easy_install is already capable of sorting through -- just a shorter one 
than the whole package index
3. There is no ramification three.  :)
4. Users who manually type a URL to find a package will get a nice helpful 
list of links.  :)
5. You can remove the full package listing.

>We will have potential (however remote) of name collision and we'll have 
>to deal with that somehow.

Yes, and we should deal with it by rejecting registration of colliding 
names.  The difference between "you can't register an identically-named 
package" and "you can't register a package that differs only in letter case 
and punctuation from another package" is very small, but also very *good* 
for human users, who are not going to be able to remember whether they want 
"Bob's very Incredible Package" or "Bob's very incredible package", or be 
able to tell the difference between "My Super Package" and "My  Super 
Package" at a glance.  (One of those names has an extra space in it, in 
case you can't tell.)

In truth, the name collision problem is already *possible*, and PyPI should 
simply reject registration for colliding package names.  Allowing people to 
register say, "SQLObject" and "sqlobject" or "Zope" and "zope" or "foo bar" 
and "Foo!Bar" as if they were actually different packages isn't doing 
anybody a favor.

Meanwhile, if you go to /pypi/SQLObject now, you get back a list of links 
that includes SQLObject2, so there's obviously some kind of mangling taking 
place for URL searches already.  If you're concerned about it being 
ambiguous, just make the fallback search result in a list of matching 
packages, *exactly the same way that going to "SQLObject" does now*, just 
with a broader match criterion:


More information about the Distutils-SIG mailing list