On 4 September 2017 at 23:33, Nick Coghlan wrote:
> 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 spe
On 4 September 2017 at 23:33, Nick Coghlan 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, rat
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
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 wrote:
> Yes, I see the inclusion of a metadata file which conforms to
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
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 wrote:
> Some time ago, I started the process [1] of adjusting how
> distutils-sig uses the P