[Catalog-sig] start on static generation, and caching - apache config.

[Phillip J. Eby]

At 11:29 PM 7/10/2007 +0200, Martin v. Löwis wrote:
>Hmm. I'm somewhat skeptical about setuptools (or any other packaging
>infrastructure, say, Debian) establishing rules on what makes a
>difference in package names.

I can certainly understand that.  However, *having* SOME definition 
that's more human-friendly (and cross-platform filename friendly!) 
than "the bytes match exactly", would be very useful to have.

If PyPI had already had one (and I asked about this when I was first 
trying to establish one) I'd have used that, or negotiated a 
compromise if it didn't meet the filename-related requirements.

However, none of the times that I asked about this issue on either 
the catalog-sig nor the distutils-sig did anyone propose any 
alternative canonicalization, nor bring up any objection besides the 
general sort of reservation that you're expressing here - i.e., not 
sure it's a good idea, but not expressing any particular reason it's 
a bad idea.

Note that Windows (and Mac OS under certain circumstances) have 
filename case insensitivity, and have different restrictions about 
what can or can't be in a filename than Unix.  Spaces and other 
punctuation characters can cause problems for shells, even if they're 
theoretically acceptable as filenames.

If you'd like to propose a *different* canonicalization, however, I'm 
certainly willing to consider implementing it in setuptools, if it 
can be done.  However, as I said, nobody has proposed anything else, 
but it would be nice to resolve the issue *before* name collisions happen.

If anything, I think that PyPI canonicalization may wish to be *more* 
restrictive than setuptools' is.  There isn't a whole lot of user 
benefit to having, say, "Mike's Nifty module" and "Mikes Nifty 
Module" being considered distinct packages, even though setuptools 
actually allows that distinction to be made.

IOW, setuptools' focus is more on distribution filename safety, 
rather than on sensible naming distinctions for end users.  The 
former is less restrictive than the latter, I believe.