Is/was there a goal with PEP 566's JSON encoding section?

Packaging
1

PEP 566 -- Metadata for Python Software Packages 2.1 | Python.org specifies how to encode core metadata in JSON. Is this just an FYI thing in case people need help encoding the data from e.g. METADATA, or is/was there a desire to try and slowly move the community over to JSON for storing this information?

I ask because I noticed two things. One, PEP 566 doesn’t specify a file name that could be used if a build tool chose to include a JSON version of METADATA or if an installer decided to add such data itself post-install (e.g. Flit and installer, respectively). Two, reading over Recording installed projects — Python Packaging User Guide made me notice that METADATA is the one file format that is intrinsically tied to Python’s stdlib (you could argue CSVs are not a standard, but the core metadata spec explicitly calls out email.parser as how you’re expected to support reading core metadata while I think how CSVs should be formatted is well understood).

2

IIRC, the goal was just to formalize how metadata could be turned into JSON, with the primary use cases being something like PyPI’s JSON API. There was never a plan to include JSON metadata in distribution files, hence nothing about filenames.

3

From what I recall, it was an experimental thing that wheel added, a METADATA.json. But it never got standardised. I do like having a formal mapping to JSON, though, even if it’s not used in any standard files.

1 Like
4

PEP 426 did call for JSON-encoded metadata files, but it was never accepted.

5

That part of PEP 426 seems to also be about carrying forward PKG-INFO data through the build process, so it doesn’t seem to touch on what a potential wheel-related file would be named.

Anyway, thanks for the info, everyone! Sounds like the lack of file name is on purpose and no specific plans were missed by leaving it out.

6

Yeah, it is odd that we have specs for so many things, but not for the basic key/value format in METADATA files. If anyone does want to fix this at some point, there’s a first pass at a formal grammar for them here. (Though for a more serious attempt, you’d want to do a lot more extensive testing against PyPI.)