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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
