Re: [Distutils] [Catalog-sig] Specification for package indexes?
Phillip J. Eby <pje@telecommunity.com> wrote: It looks like easy_install is still actually working at the moment; I guess that means you kept the list working if the user-agent is easy_install. Thank you, and sorry for jumping to conclusions. I took "This has been removed" to mean that it had been, well, removed. :)
No, I'm not sure why it didn't break - the "/" URL behaviour *had* changed to return the home page. I have reinstated the old behaviour but now we're running in mod_python we require an apache restart -- which requires a roto-rooter, so responsiveness to changes like this has just taken a significant nose-dive.
I will mention again, though, that it *can* be removed entirely, without needing any in-the-field upgrades, if project name matches in URLs can be made case-insensitive and canonical via safe_name:
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. We will have potential (however remote) of name collision and we'll have to deal with that somehow. Richard
At 03:01 AM 7/8/2006 +1000, richardjones@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: http://cheeseshop.python.org/pypi/SQLObject
participants (2)
-
Phillip J. Eby -
richardjones＠optusnet.com.au