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

[Nick Coghlan]

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia