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

[Michael Foord]

  On 18/09/2010 18:27, Nick Coghlan wrote:
> On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>>   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.
> If the idea is solely to use legacy setuptools data as a fallback if
> the actual PEP 345 data is unavailable, it sounds like it would be far
> more robust to have *PyPI* do the fallback, implementing it correctly
> *once*, rather than simply exposing the raw setuptools data (which
> *will* lead to client applications that *only* understand the
> setuptools data and can't understand packages that only provide PEP
> 345 compliant metadata).
>
> Throwing the raw data at client applications and saying "here, you
> figure it out" when they can already do that by downloading and
> interrogating the packages directly seems likely to cause more
> confusion than anything else.
>
> So +1 to a "allow_fallback_metadata" flag in appropriate PyPI APIs, -1
> on exposing the legacy data directly.
>

If the two different data formats can be exposed in a compatible way 
then this sounds good to me.

Michael

> Cheers,
> Nick.
>


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