[Catalog-sig] [Python-Dev] egg_info in PyPI
fuzzyman at voidspace.org.uk
Sat Sep 18 16:01:32 CEST 2010
Ok, I'm sorry - PEP 345 information is available via the PyPI API. (So
exposing egg_info would not be promoting it *over* distutils2 but it
would still be promoting and blessing it).
Tarek's main point still stands though. The dependency information in
the egg_info is tied to the platform and Python version that the package
was *built* on. Neither pip nor easy_install use the egg_info to
determine this; instead they re-generate it to get the correct
information for the target platform.
So if the use case is to provide dependency information exposing
egg_info is not the right way to do it - and tools that use it will be
using potentially (and frequently) inaccurate information. I stand by
the point that once we start providing this information tools will start
using it, and they shouldn't be. (So your question "when can tools
computing dependencies for widely used packages actually expect that
these metadata will be available?" is not answered by providing access
This problem (static availability of dependency information) is
*exactly* the problem PEP 345 solves, so we should be pushing for
progress on this front (distutils2a1 is already out and distutils2a2
will be out soon).
All the best,
On 18/09/2010 14:21, "Martin v. Löwis" wrote:
>> No. See above comment. If exposing this information has no value then
>> don't do it. If it does have value, then we are blessing it - and
>> therefore blessing it *over* other formats.
> No: not *over*. Only over formats that don't get exposed. However,
> the PEP 345 data are *already* exposed, via HTML, JSON, XML-RPC.
> So they are much more prominently presented than what I'm proposing
> to do. I fail to see why just extracting the egg-info would be
> exposing it *over* the PEP 345 data.
>>> The tool in question is tl.eggdepend. It can easily support both kinds
>>> of metadata.
>> I couldn't find any references "tl.eggdepend" on the web. It is a minor
>> point though.
> Oops, see http://pypi.python.org/pypi/tl.eggdeps
>> As in exported by PyPI though an API / interface?
> Sure. See, for example,
> It's also available through the XML-RPC release_data.
>> Saying that they *could* is more empty words if
>> our *actions* promote the use of another format.
> But they do. Please stop saying that they might not, when they
> actually do (and have been for a while).
>>> It's just that no package is using it (except for pep345demo).
>>> As for a bit: how long exactly?
>> Distutils2 1a2 will be released in the next few days.
> Sure. But when can tools computing dependencies for widely used packages
> actually expect that these metadata will be available?
>> Promoting another format in preference to distutils2 will very much
>> prolong that.
> IT WILL BE NOT IN PREFERENCE TO DISTUTILS2.
More information about the Catalog-SIG