On 18/09/2010 18:27, Nick Coghlan wrote:
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
<fuzzy...@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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
