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

[Daniel Holth]

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