On Tue, Feb 14, 2017 at 12:15 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Tue, Feb 14, 2017 at 10:10 AM, Vinay Sajip via Distutils-SIG > <distutils-sig@python.org> wrote: > >> humpty in term uses uses distlib which seems to mishandle wheel > >> metadata. (For example, it chokes if there's extra distribution meta and > >> makes it impossible for buildout to install python-dateutil from a > wheel.) > > > > I looked into the "mishandling". It's that the other tools don't adhere > to > > [the current state of] PEP 426 as closely as distlib does. For example, > > wheel writes JSON metadata to metadata.json in the .dist-info directory, > > whereas PEP 426 calls for that data to be in pydist.json. The non-JSON > > metadata in the wheel (the METADATA file) does not strictly adhere to > any of > > the metadata PEPs 241, 314, 345 or 426 (it has a mixture of incompatible > > fields). > > > > I can change distlib to look for metadata.json, and relax the rules to be > > more liberal regarding which fields to accept, but adhering to the PEP > isn't > > mishandling things, as I see it. > > I thought the current status was that it's called metadata.json > exactly *because* it's not standardized, and you *shouldn't* look at > it? > > It's too bad that the JSON thing didn't work out, but I think we're > better off working on better specifying the one source of truth > everything already uses (METADATA) instead of bringing in *new* > partially-incompatible-and-poorly-specified formats. > JSON-LD https://www.google.com/search?q=python+package+metadata+jsonld https://www.google.com/search?q="pep426jsonld"; PEP426 (Deferred) Switching to a JSON compatible format https://www.python.org/dev/peps/pep-0426/#switching-to-a-json-compatible-format PEP 426: Define a JSON-LD context as part of the proposal https://github.com/pypa/interoperability-peps/issues/31 This doesn't work with JSON-LD 1.0: ```json releases = { "v0.0.1": {"url": ... }, "v1.0.0": {"url": ...}, } This does work with JSON-LD 1.0: ```json releases = [ {"version": "v0.0.1", "url": ...}, {"version": "v1.0.0", "url": ...}, ] ... Then adding custom attributes could be as easy as defining a URI namespace and additional attribute names; because {distutils, setuptools, pip, pipenv(?)} only need to validate the properties necessary for the relevant packaging operation. Without any JSON-LD normalization, these aren't equal: {"url": "#here"} {"schema:url": "#here"} {"http://schema.org/url";, "#here"} This is the JSON downstream tools currently have/want to consume (en masse, for SAT solving, etc): https://pypi.python.org/pypi/ipython/json - It's a graph. - JSON-LD is for graphs. - There are normalizations and signatures for JSON-LD (ld-signatures != JWS) - Downstream tools need not do anything with the @context. ("JSON-LD unaware") - Downstream tools which generate pydist.jsonld should validate schema in tests Downstream tools: - https://github.com/pypa/pip/issues/988 "Pip needs a dependency resolver" (-> JSON) - https://github.com/pypa/warehouse/issues/1638 "API to get checksums" (-> JSON) Q: How do we get this (platform and architecture-specific) metadata to warehouse, where it can be hosted? A JSONLD entrypoint in warehouse (for each project, for every project, for {my_subset}): https://pypi.python.org/pypi/ipython/jsonld > I would accept a pull request to stop generating metadata.json in bdist_wheel. What about a pull request to start generating metadata.jsonld or pydist.jsonld instead? - [ ] "@context": { }, - [ ] "@graph": { }, # optional #PEP426JSONLD > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
