[Python-Dev] [Catalog-sig] egg_info in PyPI (original) (raw)
Michael Foord fuzzyman at voidspace.org.uk
Sat Sep 18 20:47:08 CEST 2010
- Previous message: [Python-Dev] [Catalog-sig] egg_info in PyPI
- Next message: [Python-Dev] egg_info in PyPI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 "allowfallbackmetadata" 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/
- Previous message: [Python-Dev] [Catalog-sig] egg_info in PyPI
- Next message: [Python-Dev] egg_info in PyPI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]