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

On 19 February 2013 13:59, Nick Coghlan <ncoghlan@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.