[Distutils] Meeting info re: sdists

Wes Turner wes.turner at gmail.com
Wed Oct 14 05:05:13 CEST 2015


On Oct 13, 2015 9:40 PM, "Robert Collins" <robertc at robertcollins.net> wrote:
>
> On 14 October 2015 at 15:04, Wes Turner <wes.turner at gmail.com> wrote:
> >
> > On Oct 13, 2015 7:50 PM, "Robert Collins" <robertc at robertcollins.net>
wrote:
>
> > * egg-info and dist-info should generate JSONLD
>
> The .egg-info and .dist-info directories are existing defined formats,
> I don't see any way that they can be retroactively defined as being
> JSONLD. I understand you have a JSONLD spec being discussed - this
> would be a successor to PEP-426, and Nick has put the breaks on all
> such things until we *catch up* with the already designed and defined
> work - so I'm not sure where your spec fits in things: but even
> assuming its all approved, we still can't change the meaning of
> existing in the wild artifacts.
>
> > * sdist, bdist, and wheel should update **append to** the same JSONLD
> > metadata document
>
> Why?

So that the project artifacts are traceable  through the build process; in
order to (identify sources of variance) [Requirements Traceability, 5Ws]

This is called "provenance" in real metadata circles. [W3C PROV].

>
> > * if there are additional parameters which would be necessary to
reproduce a
> > package(s), those should be included in the package metadata
>
> Why?

Because otherwise one has no idea what they are working with.

Because, for reproducibility, it's optimal to record all inputs as
structured data.

Why would we be throwing this process knowledge away? dash-delimited
filenames to indicate a phantom ABI parameter?

>
> > ... the *provenance* of these build artifacts would then be represented
in
> > the package metadata document
>
> I hate to sound like a broken record, but why? We could list the
> hashes of all the headers the C compiler consulted in generating a
> numpy extension module, but what problem are we solving.

This could be useful; we currently must use actual OS packaging to verify
per-file on-disk checksums (e.g. debsums).

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;
because there is not yet a manifest containing
(path, checksum, [perms], [fsattrs])

>
> > is this specific to sdist? nope, sorry, now is the time.
>
> The time for what?
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151013/bda3d8e5/attachment.html>


More information about the Distutils-SIG mailing list