Re: [Distutils] get_metadata in Distutils
At 08:22 PM 1/11/2009 +0100, Tarek Ziadé wrote:
On Sat, Jan 10, 2009 at 9:09 PM, Phillip J. Eby <pje@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. ;-)
On Mon, Jan 12, 2009 at 4:01 AM, Phillip J. Eby <pje@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@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/
participants (2)
-
Phillip J. Eby -
Tarek Ziadé