[Python-Dev] [Catalog-sig] egg_info in PyPI

[Michael Foord]

  On 18/09/2010 12:25, "Martin v. Löwis" wrote:
>>> I think you are misunderstanding. The infrastructure will *not* depend
>>> on the old formats. Instead, packaging that have that information will
>>> provide it, packages that don't will not. The infrastructure is 
>>> entirely
>>> agnostic on whether the data is available or not. In particular, it 
>>> will
>>> not try to interpret the data in any way.
>>>
>> No, not at all. If tools *use* the information (and if they don't then
>> what is the point?) then packages that want to be compatible with those
>> tools will have to provide this information.
>
> Not true. Tools could/should also support PEP 345 data, and then they 
> can support either kind of package.
>
But you are proposing that PyPI will provide an interface / API for 
exposing the setuptools information. So tools that get metadata from 
PyPI in this way (and depend on it - as they will if you expose it) will 
have functionality that only works for packages that provide this 
information in this form.

Saying tools "should" work with other formats too is empty words.


>> By providing information in this format PyPI will (like it or not) be
>> blessing this format as the 'standard' way of providing this
>> information.
>
> By that definition, *both* formats are "blessed". The PEP 345 data
> is already blessed. Depending on the definition of "providing", the 
> egg-info data are also already "provided", ever since PyPI started
> accepting egg files.
>
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. I accept this is not your 
intention. It *will* be the effect.

>>> I don't think this can well happen. In most known use cases, the tools
>>> could support both forms of metadata.
>> Well, a) I would like to see that demonstrated
>
> 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.

>> and b) having one
>> standard is *far* preferable and having the distutils2 format be that
>> standard is also far preferable. Please wait a bit (or start on
>> supporting the distutils2 metadata format now).
>
> The latter is already the case: the distutils2 metadata *is* supported
> *now*. 

As in exported by PyPI though an API / interface? If not then again, 
irrelevant. Tools that use the new interface you are proposing *won't* 
use that information. Saying that they *could* is more empty words if 
our *actions* promote the use of another format.

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

>
>>> That's really sad. So people will have to wait a few years to
>>> efficiently implement tools that they could implement today.
>>
>> Why a few years?
>
> Because it will take that long until a significant number of
> packages will use distutils 2. People still use very old versions
> of packaging tools (e.g. the ones that come with Debian); it will
> just take time to get the new tools and API adopted.

Promoting another format in preference to distutils2 will very much 
prolong that.

Michael

>
> Regards,
> Martin


-- 
http://www.ironpythoninaction.com/