[Distutils] metadata/versions

[Phillip J. Eby]

At 10:54 AM 3/25/2008 -0400, Alexander Michael wrote:
>On Tue, Mar 25, 2008 at 10:14 AM, Chris Withers 
><chris at simplistix.co.uk> wrote:
> > Alexander Michael wrote:
> >  > I am far from the authority on these topics, but my understanding as a
> >  > user is that PEPs 241,314,345
> >
> >  So PEP 345 is implemented in Python 2.5?
>
>Yes.
>
> >  > attempt to address these issues but are
> >  > not used in practice.
> >
> >  How come? Does distutils in 2.5 or setuptools not generate the required
> >  PKG-INFO?
>
>IIUC, as far as distutils goes, the metadata shows-up in the sdist,
>but not in site-packages, so it isn't really useful for introspecting
>an installation. The ability to specify requirements is virtually
>undocumented and isn't used in practice to my knowledge. Setuptools
>makes both pieces of information introspectable for packages it
>installs (but provides its own way of specifying requirements).

In fact, setuptools' requirements info is 100% separate from the 
PEP-specified requirements info.  Setuptools allows different 
requirements for tests, for running the setup script, and for 
optional add-ons to a project.  These requirements also use a 
different version parsing mechanism etc.

One reason for this is that Python 2.3 doesn't support this version 
stuff, and setuptools was written for 2.3 initially.  Another is that 
the PEP-defined requires/provides data does not allow dependencies to 
be satisfied merely by looking at target filenames -- i.e., without 
needing to download them.  Using a requires/provides model for 
dependency resolution would have required new PyPI infrastructure to 
be built out, whereas a filename-based approach could run on anything.

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.  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).

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.