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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
