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