[Distutils] PEP 566 - metadata 1.3 changes

Nick Coghlan ncoghlan at gmail.com
Tue Jan 16 23:55:08 EST 2018


On 17 January 2018 at 02:58, Nathaniel Smith <njs at pobox.com> wrote:
> Should wheel change to emit 1.3, or should the PEP change to become 2.0? I
> know there were great hopes for "metadata 2.0", but given that there are
> bazillions of packages out there with a metadata version of 2.0, we're never
> going to be able to meaningfully use that version number for anything else,
> and it's confusing if when reading package metadata the ordering is 1.2 <
> 2.0 == 1.3 < 1.4. So maybe we should declare that this update is 2.0 or 2.1,
> the next one will be 2.1 or 2.2, etc., and if anyone asks why the major
> version bump, well, it's hardly the strangest thing we've done for
> compatibility :-). (And in the unlikely event that PEP 426 lurches back to
> life, we can make it 3.0.)

While I never changed the title, PEP 426 actually already specifies
3.0 in https://www.python.org/dev/peps/pep-0426/#metadata-version for
exactly this reason :)

The reason for *not* making PEP 566 a major version bump is in case
anyone actually implemented this draft requirement from PEP 426:
"Automated tools consuming metadata SHOULD warn if metadata_version is
greater than the highest version they support, and MUST fail if
metadata_version has a greater major version than the highest version
they support (as described in PEP 440, the major version is the value
before the first dot)."

Metadata 1.3 is backwards compatible with metadata 1.2, so it should
keep the same major version number.

It's also an open question at this point whether or not there will
ever *be* a metadata 2.0, since we've never worked out a way to
resolve the chicken-and-egg adoption problem that arises from
proposing to publish metadata in a format that existing client tools
don't know how to read (hence the change in PEP 566 to treat the JSON
form as something to be *derived* from the line-oriented key/value
form, rather than as a replacement for it).

Cheers,
Nick.

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


More information about the Distutils-SIG mailing list