[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