[Python-Dev] Fwd: PEP 426 is now the draft spec fordistribution metadata 2.0 (original) (raw)

Daniel Holth dholth at gmail.com
Tue Feb 19 20:06:12 CET 2013

On Tue, Feb 19, 2013 at 11:26 AM, Paul Moore <p.f.moore at gmail.com> wrote:

On 19 February 2013 13:59, Nick Coghlan <ncoghlan at gmail.com> wrote: > It's OK if people don't want to read the detailed rationale provided > for each of the major changes as part of the PEP, or if they want to > dispute a particular piece of that rationale. But merely going "it's > too complicated!" or "metadata 1.2 failed, so 2.0 will fail as well!" > is not a reasonable response. Software distribution is complicated - > trying to oversimplify it is one of the reasons setuptools became > necessary.

Nevertheless, the landscape is confusing. PEPs 241, 314, 345, 426, 390, 376 and 386 are all relevant to one extent or another, and only PEPs 426 (Metadata 2.0) and 390 (Static Metadata for Distutils - setup.cfg) are still in Draft format. The others are all Accepted or Final. And yet PEPs 345, 390 and 386 are unused and likely to remain so. I believe that the only ones that are actually of use are 241, 314 and 426 (Metadata 1.0, 1.1 and 2.0, but not 1.2) and 376 (Database of Installed Python Distributions) although 376 still has a number of flaws. I'd suggest that these should be marked as Final, and the others as Rejected, so that we have a clear statement of what is actually supported. Making sure that users have the means to write code that uses these standards using functionality available in the stdlib is then the next step as you say. It is critical that this is done, because packaging tools are unique in that the barrier to using external dependencies is particularly high for them - for example, pip's reliance on distribute/setuptools is necessary, but has been problematic at times. Paul PS Apologies for using a load of PEP numbers without explanation. Here's a glossary: Metadata 1.0 - PEP 241 Metadata 1.1 - PEP 314 Metadata 1.2 - PEP 345 Metadata 1.3 - PEP 426 Static Metadata for Distutils - PEP 390 Database of Installed Python Distributions - PEP 376 Changing the version comparison module in Distutils - PEP 386

The documentation is bad.

The standard library will almost certainly grow code that can interpret these PEPs. Packaging tool authors can handle these specs but no sane person reads PEPs to figure out how to submit a simple library to pypi. No end user cares about metadata versions either or even notices that sdists contain PKG-INFO at their root. You get what setup() produces and that's it.

Wheel installers can work without being installed into the target environment at all. This is very hard to understand if you have been using the distutils model (the installed package imports the installer and packages are always rebuilt from source) for more than a decade. This feature does something to remedy the setuptools chicken/egg problem. We have eliminated the egg ;-)

Once the installer doesn't need to be installed, repeatedly, in every virtualenv, hundreds of times a day, users could just have a single up-to-date standalone copy of pip invoked as "python pip.zip install x". Additional packages needed only for builds (even setuptools) may be installed automatically by a build system (like pip) when building rather than using packages. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130219/a2fe8079/attachment.html>

More information about the Python-Dev mailing list