<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Yes, I see the inclusion of a metadata file which conforms to an
unaccepted PEP as potentially dangerous.</p>
<p>Perhaps I should disable it in the next release?<br>
</p>
<br>
<div class="moz-cite-prefix">Daniel Holth kirjoitti 04.09.2017 klo
17:03:<br>
</div>
<blockquote type="cite"
cite="mid:CAG8k2+6W_+HePq5OuJm+UzmT_2WXgL=Zrk+CLjzHO6A2g7w1vA@mail.gmail.com">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">ncoghlan@gmail.com</a>
| Brisbane, Australia<br>
_______________________________________________<br>
Distutils-SIG maillist - <a
href="mailto:Distutils-SIG@python.org" target="_blank"
moz-do-not-send="true">Distutils-SIG@python.org</a><br>
<a
href="https://mail.python.org/mailman/listinfo/distutils-sig"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Distutils-SIG maillist - <a class="moz-txt-link-abbreviated" href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a>
</pre>
</blockquote>
<br>
</body>
</html>