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