[Distutils] Meeting info re: sdists

[Robert Collins]

On 15 October 2015 at 03:35, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 14 October 2015 at 12:40, 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.
>
> I finally found time to investigate JSON-LD a while back, and I think
> there's potentially value in having the formal specification of our
> metadata formats be in the form of a JSON-LD context definition:
> https://github.com/pypa/interoperability-peps/issues/31

I can see potential value too, but the current conversations are not
revising our existing metadata formats - in fact, I think its
essential for quick deployment (which we need, because decades are too
long) that we don't trigger cascading work across the consumers of
existing formats.

> However, doing that doesn't actually solve any immediate problems for
> us, as none of our tools are JSON-LD aware, they're all based on ad
> hoc JSON processing. Thus it's firmly in the "might be nice to do"
> category for me, rather than "we need to do this as an urgent
> priority".
>
> One thing we do need to be careful of is the fact that PEP 426 is
> still a draft spec - if there are things we want to formalise *now* in
> a JSON format aimed at the *current* capabilities of the ecosystem, we
> may want to push some of the ideas like metadata extensions and the
> finer granularity of dependencies out to a more speculative metadata
> 3.0 spec, and descope 2.0 to a "only incremental additions to current
> capabilities, wrapped up in a better defined format" effort.

I believe the '426 is draft' ship has sailed: metadata.json is present
in .dist-info in wheels and has been for some time. (e.g. see
https://pypi.python.org/packages/2.7/r/reddit_bot/reddit_bot-0.1.2-py2.py3-none-any.whl#md5=86518fc20388c1d8e567cf2d4cfe1a03
). As such we're going to need to take the 'compatible changes to it
in-place, incompatible changes need a new schema version' approach
IMO.

Otherwise, when we start consuming it, we'll be reading draft versions
and assigning different meanings.

I think future specs should issue the final version in the schema only
when the PEP is made non-draft.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud