[Distutils] get_metadata in Distutils

Phillip J. Eby pje at telecommunity.com
Mon Jan 12 04:01:22 CET 2009


At 08:22 PM 1/11/2009 +0100, Tarek Ziadé wrote:
>On Sat, Jan 10, 2009 at 9:09 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> >>
> >> Since this is basically what has been done in setuptools, I thaught
> >> that you might wanted to help around for this change ?
> >
> > I'd suggest looking at the pkg_resources code, particularly
> > find_distributions and its related functions.
>
>Ok thanks,
>
> > Note, for example, that egg
> > layouts can be nested (even when zipped!), and that the metadata can have
> > different filenames, depending on the installation format.
>
>This is my understanding at this stage :
> From a Distutils point of view, it seems that this would suffice to
>read the metadata from the egg-info files :
>
>1/ add in distutils.dist.DistributionMetadata a new method to be able
>to load an existing egg-info file
>2/ add in the pkgutil module, the get_metadata function, that could
>have this signature:
>
>    get_metadata(package_name, path_item)
>
>where path_item is a site-packages like directory,
>
>this function would scan the path_item directory, like what
>setuptools.pkg_resource code does,
>and return the metadata (+fill a cache with all packages metadata found)

My point was that if you don't support .egg files or 
EGG-INFO/PKG-INFO, then your API is rather crippled; there is no 
reason for anyone using setuptools to use it in place of the 
corresponding pkg_resources API, as it simply will not work with 
packages installed by easy_install.


> > Version parsing
> > also has certain peculiarities, which also means that people doing simple
> > string comparisons on the version field is probably not going to suffice.
>
>Wouldn't distutils.versionpredicate be useful here ?

Only if the package in question follows distutils' rules, which 
aren't as flexible as those of setuptools...  and setuptools' version 
parsing system was designed to handle a significant number of 
versioning schemes that were in use on PyPI at the time -- schemes 
that the distutils mostly couldn't parse correctly.

I'm just trying to warn you that adding these features in a 
distutils-only way could easily end up like the PKG-INFO "requires" 
and "provides" fields -- that is, theoretically useful but of no 
practical value to anyone.  In fact, they could be "attractive 
nuisances" in that they would encourage people to use them, only to 
find out later that it was a complete dead end because of the lack of 
support for anything but pure-distutils packages.

Of course, they will then blame me and setuptools rather than you and 
the distutils, but I suppose I'm used to that.  ;-)



More information about the Distutils-SIG mailing list