[Distutils] How to get list of package requirements from PyPI without downloading egg?
Phillip J. Eby
pje at telecommunity.com
Thu Oct 26 17:21:43 CEST 2006
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.
More information about the Distutils-SIG
mailing list