<p dir="ltr"><br>
On 27 Feb 2014 04:00, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
> ><br>
> > I will accordingly be updating the defined metadata version in PEP 426<br>
> > to 3.0, and including an explicit admonition to *never* include<br>
> > experimental metadata (whether in the base format or as part of an<br>
> > experimental extension) in the main pydist.json file. Experimental<br>
> > metadata should only ever appear in tool-specific files (which don't<br>
> > need to guarantee any kind of interoperability with other tools).<br>
> ><br>
> > In the meantime: please don't publish pydist.json files, use some<br>
> > other filename if you want to experiment with JSON based metadata in<br>
> > advance of the acceptance of PEP 426.<br>
> ><br>
> > Regards,<br>
> > Nick.<br>
><br>
> This shouldn’t matter. Tools shouldn’t be trusting a pydist.json just because<br>
> one exists and the Wheel format should have a version bump before you<br>
> can start trusting them anyways.</p>
<p dir="ltr">It's post-install and *post PEP 426 acceptance* that concerns me. Once PEP 426 is accepted, we'll need a reliable way to distinguish pydist.json files in the standard format from these experimental prototypes.</p>

<p dir="ltr">Now, we could add some extra validity rules (such as "must come from a 1.1+ wheel file or a 2.0+ sdist"), but that seems fragile to me, since those markers likely won't be available once the package is installed.</p>

<p dir="ltr">By contrast, skipping straight to 3.0 will make it easy for tools to distinguish between files that are intended to be PEP compliant, and those that may contain data in formats based on an earlier draft.</p>

<p dir="ltr">That said, I guess another alternative is to handle it through parsing error fallbacks, and include a recommendation in PEP 426 that if pydist.json is missing or fails to parse correctly, they should fall back to checking for setuptools style metadata.</p>

<p dir="ltr">If Vinay is happy with that last option for handling the current bdist_wheel misbehaviour that would mean we could leave the metadata version alone, and just add the guidelines regarding publishing draft metadata and handling malformed or missing metadata.</p>

<p dir="ltr">Cheers,<br>
Nick.<br>
</p>