On 15 October 2015 at 03:35, Nick Coghlan <ncogh...@gmail.com> wrote: > On 14 October 2015 at 12:40, Robert Collins <robe...@robertcollins.net> wrote: >> On 14 October 2015 at 15:04, Wes Turner <wes.tur...@gmail.com> wrote: >>> >>> On Oct 13, 2015 7:50 PM, "Robert Collins" <robe...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
