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. _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
