At 12:53 AM 10/26/2006 -0600, Jeremy Kloth wrote: >On Thursday 26 October 2006 12:21 am, Phillip J. Eby wrote: > > At 12:05 AM 10/26/2006 -0600, Jeremy Kloth wrote: > > >Except Cheeseshop already supports the PEP 314 metadeta fields Requires, > > >Provides and Obsoletes. They are available to all packages built with > > > Python 2.5 distutils. > > > > Indeed it does... but that information is both unused and useless at the > > moment. > >Could it be that it is unused because Pyhon 2.5 was just released? That is >when these fields made it into Distutils.
That could be why it's unused; but not why it's useless. No agreement on semantics simply means that the odds are astronomically against anyone putting in data that can actually be used by someone else. You would *first* need to create a tool that could do something useful with the information, and second, you'd need it to be something that actually *tested* the usefulness -- meaning you'd need a distutils extension, or else you'd have to wait until 2.6 to add new features to distutils itself. (If the data can't be tested by the person putting it in their setup() script, then it will be wrong, and therefore useless to others for any sort of automated dependency resolution.) >So how do you specify an exact platform and Python version with setuptools' >install_requires? They are, IMO, used at the same level. install_requires is set by a script, so the script can set it based on the Python version and platform the script is running on. Thus, eggs built for different platforms or Python versions can have different requirements. > > Personally, I think PEP 314 should be rejected, as this issue is only one > > of its flaws. I'm surprised to see it is now marked "final", given the > > near total lack of discussion on it, except for me periodically posting > > about its flaws (since 2005, no less). None of the new fields except > > Download-URL are actually useful. > >It is a little late now. Those fields are part of Python 2.5 so they are >going to be around for at least 3 more years (if the 2.3 to 2.5 timeline is >any indicator). So how about doing something to actually *improve* the fields >besides just complaining? If there were a *way* to improve them, I'd have suggested it a long time ago. >Going forward with (probable) modifications to the fields' allowed values, it >should be fairly easy to expand the allowed values as the need arises since >the current values are so restrictive. Until somebody has some idea of 1) what the semantics are, and 2) what the use cases for those semantics are, the fields aren't of any value whatsoever. This isn't something that's going to be improved by fiddling with their syntax, so long as the semantics remain undefined. > > PEP 314 delenda est. > >Now there is a postitive attitude... Well, I'm pretty positive that it delenda est. :) In truth, however, it's just a lame duck that won't fly, doomed to irrelevance in the bigger scheme of things. It would take a heroic effort to make anything useful out of it, and there's no incentive for anybody to make that effort. So, from my POV, the only useful forward action is to put it out of its misery, since the only other thing that's ever going to happen with it is talk, and maybe a few people putting some useless and incompatible things in there. You need some kind of community that wants to specify dependencies, but *doesn't* want anybody to be able to automatically install them! Or else, that develops its own set of tools for automatic installation... that only works with packages whose users followed that new tool's conventions. In effect, you need a community large enough to create its own mini-PyPI... and that isn't already using setuptools dependencies to do the same thing. Or, you need to have it use the metadata in a style similar to setuptools, in which case you're limited by PEP 314's crazy syntax restrictions, that aren't compatible with existing PyPI distribution names. About the only thing that could possibly outweigh all that is a BDFL proclamation in favor of some particular semantics... which nobody has proposed or agrees upon as yet. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
