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