[Distutils] metadata/versions

Chris Withers chris at simplistix.co.uk
Wed Mar 26 19:06:29 CET 2008

Phillip J. Eby wrote:
> to download them.  Using a requires/provides model for dependency 
> resolution would have required new PyPI infrastructure to be built out, 

I find it shocking that PyPI doesn't have either a human or machine 
readable list of dependencies for each version of each package.
I mean really, even as a human, how am I supposed to look at a package 
and PyPI and figure out what else it needs and if it's going to be 
compatible with my current set of installed packages?

> PyPI and the requires/provides PEPs also appear to carry an implicit 
> assumption that these requires/provides are leveled on project+version, 
> without any distinction by Python version and target platform.  

True enough. I guess requirements becomes:

- the current python version
   (although, in the absence of a version-specific package, I'd imagine a
    non-version-specific package should suffice)
- the current architecture
   (although, in the absence of an architecture-specific package, I'd
    imagine a architecture-independent package should suffice)

Still, I wonder if the strategy should be inverted. What I usually end 
up doing by hand is:

- if the package has extension modules:

   - if I'm on unix, download the source install, run setup.py install

   - if I'm on windows, download the python-specific installer. If none
     is available, bin the package

- if the package has no extension modules, download the source install 
and run setup.py install

Of course, there's also a great deal of "wtf version of packagex do I 
currenlty have installed anyway?!" as well :-(

> Setuptools OTOH, assumes that specific dependencies are a property of a 
> *binary* distribution, not a source distribution.  (i.e., the PEPs put 
> the dependency info in a source package's PKG-INFO...  where it's pretty 
> much useless for any purpose).

Yeah, something like PKG-INFO should appear somewhere standard in 
whatever ends up in site-packages or similar...

> I've previously posted some of these comments about the 
> requires/provides PEPs on Python-Dev, Distutils-SIG, and Catalog-SIG, 
> with no response from anyone.

You're making the fatal assumption that people who have views about 
these things appear on these SIGs :-(
I've cared for many years but only found out about the distutils-sig 
relatively recently. Dunno what catalog-sig is and I don't think I 
belong anywhere near python-dev ;-)


Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk

More information about the Distutils-SIG mailing list