[Distutils] Migrating interoperability specs to packaging.python.org

[Alex Grönholm]

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 <ncoghlan at gmail.com 
> <mailto:ncoghlan at 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   | ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>
>      |   Brisbane, Australia
>     _______________________________________________
>     Distutils-SIG maillist  - Distutils-SIG at python.org
>     <mailto:Distutils-SIG at python.org>
>     https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170904/78d6e058/attachment.html>