[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