At 08:21 PM 7/24/2007 +0200, Martin v. Löwis wrote:
Because if case actually made a difference, we couldn't have both packages installed in the same directory, could we?
Right. However, there is a difference between case-insensitive, and case-preserving.
I don't understand your statement here, nor what is supposed to follow from it.
Clearly, on a case-insensitive file system, project names differing only in case cannot coexist. That doesn't mean that all references to the project should be case-normalized (e.g. lower-cased).
So even if project names compare case-insensitive, there still should (could) be a "right" spelling, the one that the package author wants to see. This is the spelling that others then should use.
Well, that spelling will certainly show up everywhere. Setuptools is case-preserving, *except* with regard to installing egg files on case-insensitive filesystems (as defined by what os.path.normcase does on a given platform). When it installs an egg, it normalizes the case of the target path. In all other matters it is case-insensitive for comparison, but case-preserving of the inputs it receives.
Jim's objection was that if it's possible to get case-correction from the index, people will declare setup.py dependencies with incorrect case, leading to other packages having indirect dependencies with incorrect case, leading to lots of package index lookups.
I don't think that was his objection. IIUC, he complains about incorrect spellings as bad, period - regardless of whether they also have a performance effect. It's like spelling your name "Philipp" - that's a bad thing to do, independent of whether it also makes you harder to find (which it actually doesn't, thanks to Google).
It's actually more like spelling my name "phillip", which is arguably still spelled correctly, if punctuated poorly. :) And it's also an answer to the wrong question: the *first* question is whether we should allow "phillip" and "Phillip" to co-exist in the package index. If not, then there is the question of whether there is any reason to be case-sensitive with respect to searching. If we are agreed that having projects whose names differ only by case is a bad idea, then the latter question is considerably less controversial.
This objection is relevant only to requirements which differ from the actual project name only by their case. A non-registered package lookup is going to fail no matter what, and thus isn't going to wind up in a setup.py without a dependency_links specifier that will prevent it being looked up in the package index to begin with.
Right. However, if setuptools would stop making case insensitive lookups to the index, lookups to unregistered packages would become more efficient.
I'm not sure I follow you. If a non-registered package is used as a dependency, the setup() will need to specify dependency_links, in which case PyPI will not be consulted.