[Distutils] get_metadata in Distutils

[Tarek Ziadé]

On Mon, Jan 12, 2009 at 4:01 AM, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

Ok, I will introduce in my patch the other formats. I am wondering though, how
far this would be from an integration of pkg_resources into Distutils/pkgutil,
with some API on the top and if it makes sense.

The only difference I can see is that I am working on an API that would return
DistributionMetadata instances

http://bugs.python.org/file12692/get_metadata.diff

>
>
>> > 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'd say then : if setutpools version parsing system is superior to
distutils.versionpredicate,
wouldn't it make sense to merge it into Distutils ?

Maybe that was the initial plans ?

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

Well, being able to query the installed version for a package seem to
me like a feature
that should live in Distutils or pkgutil

In the same way, being able to do version arithmetic is rather
important, and it would be better
ihmo to have one and only one way to deal with that in Python,

What are you plans for Setuptools development for the future ?

On Distutils side, I am trying to list what could be done and propose
a list here,

Regards,

Tarek

-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/