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

[Jim Fulton]

On Jul 10, 2007, at 6:18 PM, Phillip J. Eby wrote:
> 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.

I think it is time we (the Python community) nailed this down.   
Perhaps a distribution project-name naming PEP is in order.

>
> 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.

Why should this imply case insensitivity of distribution project  
names.  Python has case sensitive module (including package) names  
that can lead to problems if two modules have names that differ only  
in case.  (I assume that Python 3000 retains this although, sadly, I  
don't know.)  We deal with this by telling people "don't do that."   
Two packages with the same name except for case are incompatible, but  
then, so are modules with incompatible dependencies.

> 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.

I don't care much what canonicalization we use, but I agree strongly  
that we should decide something.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org