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

[Alex Grönholm]

Yeah, so we should maybe start using the upcoming v1.3 metadata when the 
related PEP is accepted...?


Daniel Holth kirjoitti 04.09.2017 klo 17:48:
>
> 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.
>
>
> On Mon, Sep 4, 2017, 10:06 Alex Grönholm <alex.gronholm at nextday.fi 
> <mailto:alex.gronholm at nextday.fi>> wrote:
>
>     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 <mailto:Distutils-SIG at python.org>
>>     https://mail.python.org/mailman/listinfo/distutils-sig
>
>     _______________________________________________
>     Distutils-SIG maillist  - Distutils-SIG at python.org
>     <mailto: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/d70a1449/attachment.html>