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