The PEP 621 discussion is getting derailed by questions of sdist standardisation. Rather than cause PEP 621 to fail because of unrelated issues, I’d like to propose a very focused change to the sdist standard(s) to attempt to make sdist metadata usable.
We already have a standard that mandates that a sdist has a
PKG-INFO file containing metadata. I propose the following changes:
- Update the spec to say that
PKG-INFOMUST conform to [the current metadata standard] (https://packaging.python.org/specifications/core-metadata/). PEP 517 mandates metadata version 1.2, so this is a long overdue change anyway.
- Add a metadata field
Dynamicmodeled on the PEP 621
Dynamicfield is multiple use and contains any medatdata field name EXCEPT ones on the following list: Name, Version, Summary, Description, Requires-Python, License, Author, Author-email, Maintainer, Maintainer-email, Keywords, Classifier, Project-URL.
Dynamic field could be added to the core metadata spec, or it could be a sdist-specific extension. I don’t really mind, but I think the core metadata spec technically disallows extra fields, so adding it to the spec would be easier.
The semantics of the
Dynamic field would be that it is only allowed in a sdist, and that it is multiple-use and contains a metadata field name. Wheels built from a sdist MUST NOT add or change the value of metadata fields that are not listed in
I think we’ll need a way of flagging sdists that conform to the above spec, as it’s not backward compatible (current sdists don’t effectively allow every field to be dynamic, but don’t say so). Assuming we add
Dynamic to the core metadata as metadata version 2.2, this can just be “sdists that write metadata version 2.2 and later”.
If this idea is broadly acceptable, in particular to the build backend maintainers (cc @pganssle, @takluyver, @sdispater, @steve.dower) then I’ll write it up as a formal update to the core metadata spec and a PEP. It would need a PEP-delegate - @pganssle would you be willing to take on that role?