[Distutils] Major update to the metadata 2.0 draft PEPs

[Nick Coghlan]

I've just published the first draft of the metadata 2.0 spec that
moves all of the fields that aren't part of the core metadata or
potentially needed for dependency resolution out to a separate
"standard metadata extensions" PEP.

I think this makes PEP 426 itself substantially less overwhelming, and
also provides convenient names to refer to the various other subsets
of the metadata. The new PEP defining the standard extensions is PEP
459.

Metadata 2.0: http://www.python.org/dev/peps/pep-0426/
Versioning: http://www.python.org/dev/peps/pep-0440/
Standard Extensions: http://www.python.org/dev/peps/pep-0459/

You can see the full deltas for PEP 426 and PEP 440 here:
http://hg.python.org/peps/rev/d18629859154

Or slightly more incremental deltas in the BitBucket repo:
https://bitbucket.org/pypa/pypi-metadata-formats/overview

With this update, I believe PEP 440 is extremely close to acceptance,
as I have tried to resolve a number of problems Donald noted while
working on Warehouse, as well as the perennial problem of how to deal
with versioning of packages where Linux distro vendors (or other
system integrators) have applied additional patches.

The PEP 440 changes:

- added the "integrator suffix" (essentially an extra release segment,
separated from the upstream version number by "-"). It is effectively
ignored by most of the matching operators, but sorts as a higher
version than the version with no suffix.
- allowed date based versions for most purposes, but still reject them
for the "~=" compatible version operator. The implied comparison
operator for date based versions is ">=".
- clarified that zeroes and leading zeroes are permitted and that they
should be sorted like numbers
- based on discussions with some of the Red Hat security folks, I
tweaked the direct URL references to *always* require a hash in the
URL, even when using HTTPS or SSH.

PEP 426 and PEP 459 are further away from finalisation, but we're
definitely getting closer to something I'm happy with.

The PEP 426 changes:

- many of the fields are gone, having moved to PEP 459 extensions
- this also allowed the notion of "essential dependency metadata"
(with it's own separate filename) to go away
- the extension format changed to require a submapping
- extensions are now versioned (with an implied 1.0 if not specified)
- as with direct URLs in PEP 440, source URLs are now required to contain a hash

PEP 459 overview:

- standard extensions using the "python.*" namespace
- the details, project, exports and commands extensions just lift
several fields out of PEP 426
- the integrator extension is new, and matches the project extension
structure. It allows redistributors like a Linux distro or a Python
vendor to add their own info without overwriting the upstream project
metadata
- the new metadata_hooks extension replaces the install hooks design
in earlier drafts of PEP 426. In this new scheme, Twisted, for
example, would define an appropriate export group hook in order to be
told about any new extensions that exported Twisted plugins and take
appropriate action

In this revised metadata model, distributions *will* trigger their own
postinstall metadata hooks, but won't trigger their postuninstall
hooks.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia