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

"Martin v. Löwis" martin at v.loewis.de
Sat Sep 18 12:03:58 CEST 2010


> 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.

> 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. 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.

> 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.

Regards,
Martin


More information about the Python-Dev mailing list