<p dir="ltr">Well, none of the metadata generated by bdist wheel conforms to an accepted pep. But if you rely on the json file then you won't be interoperable with wheels from any other generator.</p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 4, 2017, 10:06 Alex Grönholm <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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></div><div text="#000000" bgcolor="#FFFFFF">
<br>
<div class="m_1882571272938034520moz-cite-prefix">Daniel Holth kirjoitti 04.09.2017 klo
17:03:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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>
<br>
<fieldset class="m_1882571272938034520mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Distutils-SIG maillist - <a class="m_1882571272938034520moz-txt-link-abbreviated" href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a class="m_1882571272938034520moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<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>