[Python-Dev] [Catalog-sig] egg_info in PyPI (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Sat Sep 18 14:24:03 CEST 2010

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.

By providing information in this format PyPI will (like it or not) be blessing this format as the 'standard' way of providing this information. By that definition, both formats are "blessed". The PEP 345 data is already blessed. Depending on the definition of "providing", the egg-info data are also already "provided", ever since PyPI started accepting egg files. No. See above comment. If exposing this information has no value then don't do it. If it does have value, then we are blessing it - and therefore blessing it over other formats. I accept this is not your intention. It will be the effect.

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 The tool in question is tl.eggdepend. It can easily support both kinds of metadata. I couldn't find any references "tl.eggdepend" on the web. It is a minor point though.

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). The latter is already the case: the distutils2 metadata is supported now.

As in exported by PyPI though an API / interface? If not then again, irrelevant. Tools that use the new interface you are proposing won't use that information. Saying that they could is more empty words if our actions promote the use of another format.

It's just that no package is using it (except for pep345demo).

As for a bit: how long exactly? Distutils2 1a2 will be released in the next few days.

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? Because it will take that long until a significant number of packages will use distutils 2. People still use very old versions of packaging tools (e.g. the ones that come with Debian); it will just take time to get the new tools and API adopted.

Promoting another format in preference to distutils2 will very much prolong that.

Michael

Regards, Martin

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

More information about the Python-Dev mailing list