<p dir="ltr"><br>
On Oct 13, 2015 9:40 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> On 14 October 2015 at 15:04, Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br>
> ><br>
> > On Oct 13, 2015 7:50 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> > * egg-info and dist-info should generate JSONLD<br>
><br>
> The .egg-info and .dist-info directories are existing defined formats,<br>
> I don't see any way that they can be retroactively defined as being<br>
> JSONLD. I understand you have a JSONLD spec being discussed - this<br>
> would be a successor to PEP-426, and Nick has put the breaks on all<br>
> such things until we *catch up* with the already designed and defined<br>
> work - so I'm not sure where your spec fits in things: but even<br>
> assuming its all approved, we still can't change the meaning of<br>
> existing in the wild artifacts.<br>
><br>
> > * sdist, bdist, and wheel should update **append to** the same JSONLD<br>
> > metadata document<br>
><br>
> Why?</p>
<p dir="ltr">So that the project artifacts are traceable  through the build process; in order to (identify sources of variance) [Requirements Traceability, 5Ws]</p>
<p dir="ltr">This is called "provenance" in real metadata circles. [W3C PROV].</p>
<p dir="ltr">><br>
> > * if there are additional parameters which would be necessary to reproduce a<br>
> > package(s), those should be included in the package metadata<br>
><br>
> Why?</p>
<p dir="ltr">Because otherwise one has no idea what they are working with.</p>
<p dir="ltr">Because, for reproducibility, it's optimal to record all inputs as structured data.</p>
<p dir="ltr">Why would we be throwing this process knowledge away? dash-delimited filenames to indicate a phantom ABI parameter?</p>
<p dir="ltr">><br>
> > ... the *provenance* of these build artifacts would then be represented in<br>
> > the package metadata document<br>
><br>
> I hate to sound like a broken record, but why? We could list the<br>
> hashes of all the headers the C compiler consulted in generating a<br>
> numpy extension module, but what problem are we solving.</p>
<p dir="ltr">This could be useful; we currently must use actual OS packaging to verify per-file on-disk checksums (e.g. debsums).</p>
<p dir="ltr">e.g. we actually currently have no idea if the uncompressed archive files differ from the checksummed archive, unless we re-download and compare with an archive manifest;<br>
because there is not yet a manifest containing<br>
(path, checksum, [perms], [fsattrs])</p>
<p dir="ltr">><br>
> > is this specific to sdist? nope, sorry, now is the time.<br>
><br>
> The time for what?<br>
><br>
> -Rob<br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
</p>