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

[Phillip J. Eby]

At 07:16 AM 7/11/2007 +0200, Martin v. Löwis wrote:
> > 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.
>
>I can see that collisions should be avoided in advance when it comes to
>file names. However, the name of a software package is not necessarily a
>file name,

Actually, it is.  The distutils generate distribution filenames based on this.


> > 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.
>
>Yes. However, it's not clear to me that the infrastructure needs to
>(or even is able to) enforce sensible naming.

I said sensible *distinctions* - not sensible naming.  Clearly, we 
can't advise people not to publish packages named "Joe's 
Miscellaneous Functions", at least not in an automated way.  :)


>  Instead, any policing
>that might be necessary should be done in the community. If two
>packages are named too similarly, users will get confused, and
>eventually one package may disappear, get renamed, get its naming
>challenged in court, and so on. It's not the job of the package
>*index* to do that sort of policing.

Within its own scope, that's a valid and sensible argument.  Within 
the larger scope of "what is good for users", I would say it does no 
*good* to allow people to register such similar package names, and in 
many cases will do *harm* to do so.

Contrariwise, it will not do *harm* to anyone to reject their 
too-similar name, and will in fact do them good.  Today, I almost 
created a package called "Aspects".  Had I done so, and uploaded it 
to the Cheeseshop, I wouldn't have been warned that there is already 
a package named "aspects".  I would have been well on my way to 
creating confusion that would be entirely avoidable, were the 
Cheeseshop to stop me at the point of registration or uploading.

Since the restriction can cause no real harm, and produces a net 
good, but the lack of restriction can cause real harm (e.g., I had to 
later change a package name, thereby breaking dependencies in other 
packages), there is no reason *not* to provide that benefit to the 
users, and protect them from that harm.

Perhaps, as Jim says, it is time to start treating PyPI as part of 
the packaging system.  It is so in fact, anyway.  Meanwhile, the 
separation between cataloging and packaging means other issues, such 
as the complete disconnect between the cataloging of metadata and the 
automated production and use of such metadata.  The PKG-INFO format 
has been degrading with each new version, in terms of defining more 
metadata for which over-restrictive *syntax* is defined, while being 
almost completely lacking in any *semantics*.

This schism between the idea of neatly cataloging things, versus 
being able to actually *use* that cataloging for practical purposes 
by automated tools (as opposed to being usable only to human 
readers), seems to be at the heart of some of the current discussion.