[Distutils] Migrating interoperability specs to packaging.python.org

Daniel Holth dholth at gmail.com
Mon Sep 4 10:03:22 EDT 2017

Some people enjoy using metadata.json which tracked pep 426 but I have been
meaning to take it out, and perhaps keep the key/value to json converter as
a command.

On Mon, Sep 4, 2017, 09:33 Nick Coghlan <ncoghlan at gmail.com> wrote:

> Some time ago, I started the process [1] of adjusting how
> distutils-sig uses the PEP process so that the reference
> specifications will live on packaging.python.org, and we use the PEP
> process to manage *changes* to those specifications, rather than
> serving as the specifications themselves (that is, adopting a process
> closer to the URL-centric way the Python language reference is
> managed, rather than using the RFCstyle PEP-number-centric model the
> way we do now).
> I never actually finished that work, and as a result, it's currently
> thoroughly unclear [2] that Description-Content-Type and
> Provides-Extra are defined at
> https://packaging.python.org/specifications/#core-metadata rather than
> in a PEP.
> I'm currently at the CPython core development sprint in San Francisco,
> and I'm thinking that finalising that migration [3] and updating the
> affected PEPs accordingly (most notably, PEP 345) is likely to be a
> good use of my time.
> However, I'm also wondering if it may still be worthwhile writing a
> metadata 1.3 PEP that does the following things:
> 1. Explicitly notes the addition of the two new fields
> 2. Describes the process change for packaging interoperability
> specifications
> 3. Defines a canonical transformation between the human-readable
> key:value format and a more automation friendly JSON format
> That PEP would then essentially be the first one to use the new
> process: it would supersede PEP 345 as the latest metadata
> specification, but it would *also* redirect readers to the relevant
> URL on packaging.python.org as the canonical source of the
> specification, rather than being the reference documentation in its
> own right.
> Cheers,
> Nick.
> [1] https://github.com/pypa/pypa.io/issues/11#issuecomment-173833061
> [2] https://github.com/python/peps/issues/388
> P.S. Daniel, if you're currently thinking "I proposed defining an
> incremental metadata 1.3 tweak years ago!", aye, you did. My
> subsequent additions to PEP 426 were a classic case of second-system
> syndrome: https://en.wikipedia.org/wiki/Second-system_effect (which we
> suspected long ago, hence that PEP's original deferral)
> Fortunately, the disciplining effect of working with a primarily
> volunteer contributor base has prevented my over-engineered
> change-for-change's-sake-rather-than-to-solve-actual-user-problems
> version from becoming reality ;)
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170904/bdbb4b39/attachment-0001.html>

More information about the Distutils-SIG mailing list