Yes, I see the inclusion of a metadata file which conforms to an
unaccepted PEP as potentially dangerous.
Perhaps I should disable it in the next release?
Daniel Holth kirjoitti 04.09.2017 klo 17:03:
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 <ncogh...@gmail.com
<mailto:ncogh...@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
<http://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 <http://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 <mailto:ncogh...@gmail.com>
| Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
<mailto:Distutils-SIG@python.org>
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
