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

[Michael Foord]

  On 18/09/2010 11:03, "Martin v. Löwis" wrote:
>> With the distutils2 work very close to landing in the standard library,
>> providing infrastructure that will cause tools to *depend* on the old
>> formats is a very bad idea.
>
> 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. That will require those 
packages to use setuptools and prevent them using distutils2.

By providing information in this format PyPI will (like it or not) be 
blessing this format as the 'standard' way of providing this 
information. That I think is a very bad idea at this point in the 
evolution of Python packaging tools.

>> If tool use this metadata then it could well
>> prevent packages that want to be compatible with these tools from using
>> distutils2.
>
> I don't think this can well happen. In most known use cases, the tools
> could support both forms of metadata. 
Well, a) I would like to see that demonstrated and b) having one 
standard is *far* preferable and having the distutils2 format be that 
standard is also far preferable. Please wait a bit (or start on 
supporting the distutils2 metadata format now).

> It may be that tools want to use
> information that is not provided by PEP 345. However, the tool will then
> likely fall back to just not having the information, as even existing
> packages only provide that information occasionally.
>
>> What PyPI does effectively becomes "the standard" for a large chunk of
>> the Python world (which is why changing the format PyPI provides data in
>> can be so hard). Now seems a really dumb time to bless the setuptools
>> metadata format as the defacto standard after so much work has gone into
>> replacing it and that effort is so close to completion.
>
> Please understand that the information is not being "blessed"
> (in any sense of the word that comes out of the dictionary). It's just
> being made available slightly more conveniently - please understand that
> it was available all the years already.
>

I'm sorry but this is wrong. By providing this information about 
packages in the *standard* Python package repository it is very much 
(whether intentionally or not) blessing it as a standard.

>> So - I agree with Tarek. Exposing this information on PyPI would be
>> problematic for the Python community. Not only does the data have the
>> problems that Tarek and Sridhar point out, but it would actively hinder
>> adoption of the better replacement.
>
> That's really sad. So people will have to wait a few years to 
> efficiently implement tools that they could implement today.

Why a few years?

All the best,

Michael

>
> Regards,
> Martin


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