Metadata 2.2 and later - When there is no "Dynamic" metadata specified

The first thing I should say here is that this only affects sdists in practice, as PEP 643 explicitly states “consumers MUST NOT assume that the lack of a Dynamic marking has any significance, except in a source distribution”.

PEP 643 states the following about the “Dynamic” metadata item:

A new field, Dynamic , will be added to the Core Metadata Specification. This field will be multiple use, and will be allowed to contain the name of another core metadata field.

When found in the metadata of a source distribution, the following rules apply:

  1. If a field is not marked as Dynamic , then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as Dynamic , then it MUST NOT be present in the wheel.
  2. If a field is marked as Dynamic , it may contain any valid value in a wheel built from the sdist (including not being present at all).
  3. Backends MUST NOT mark a field as Dynamic if they can determine that it was generated from data that will not change at build time.

What this does not say, is what it means if a source distribution explicitly uses metadata 2.2 (or later), but has no “Dynamic” field at all. It states (rule 1) what it means for a field to not be marked as dynamic, but only in the context of “When this (field) appears”.

In principle, it seems obvious that if there is no “Dynamic” metadata, then every field is static by default. And I think that was my original intent here, as I was only thinking in terms of sdist building tools upgrading to implement metadata 2.2, where stating the metadata version was enough to mark the intent.

However, the situation is less obvious once we have post-2.2 metadata versions. If we take, for example, the proposed license expression metadata, then I can imagine a build backend like setuptools wanting to implement that feature independently of whether they are ready to implement PEP 643. But in order to do so, and not “accidentally” mark all sdist fields as static, they will need to add “Dynamic: xxx” metadata for every field currently in the sdist metadata (exceot name and version, which cannot be dynamic). This is not a huge problem, but it would be easy to forget, and projects may be uncomfortable about it, as it means either having to make an unnecessarily negative claim about the reliability of the given metadata, or having to complicate the (unrelated) license expression change by making decisions on what is static or dynamic.

Are people happy with the above? If my concern about having to be explicit about dynamic fields is not an issue in practice, I’ll amend the “backwards compatibility” section of the PEP, and the metadata specification, to make this explicit.

If people would prefer the lack of “Dynamic” to signal “we haven’t thought about this yet” for backward compatibility, then we have a different problem - there’s no way to say “we have thought about this, and everything is indeed static”. We could use a special name, say “Dynamic: none”, to signal this. I’m not particularly happy with that idea, so alternative suggestions are welcome.

Unless people object, I’m going to assume that the straightforward reading of the current text (no dynamic means everything is static) is correct, and submit a clarification to that effect. But I want to raise the question now, because post-2.2 metadata versions are being discussed, and I don’t want to cause problems for their adoption because this point isn’t clear.

2 posts were split to a new topic: Non-sequential acceptance and implementation of new Core Metadata features and changes