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

[Daniel Holth]

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>