I’d been thinking about the issue discussed there, namely adoption of the Dynamic
field being a blocker for potential implementations of PEP 639, back when originally rewriting PEP 639, and I think it might point to a broader one (maybe better opened as another thread?), especially given the current state of the packaging ecosystem viz. the lag between specification and implementation, the variances between different tools, and the framing of PEP as proposals for specific discrete changes.
Specifically, because the metadata version is currently incremented with each PEP, the specifications and the frontend and backend implementations are both numerous and decoupled, and PEPs vary in complexity and discreteness, the order in which core metadata features are implemented in any given backend, frontend or other tool may not align with the order the PEPs happen to be accepted and PRs to core metadata are made, but there is no way to indicate support of a “later” feature without an earlier one. Furthermore, the proposed new metadata version in each PEP may switch around depending on the order in which PEPs are accepted, leading to potential confusion and inaccurate assumptions.
For example, some changes which are incremental tightening and clarifications of previous specifications, such as PEP 685, which tools would likely want to adopt quickly, and many tools may already implement in practice. Other PEPs add a new field (PEP 643), that intersects with but does not directly change the other fields. Still other PEPs both add new field(s) and deprecate existing ones (PEP 639); this case is particularly problematic when tools implement a draft version of the field that may change its semantics in the final implementation (as Wheel and Setuptools now have with License-Files
), so the version is the only way to reliably indicate whether the field has the standardized semantics specified by that metadata version.
On one hand, besides being the status quo, the current version scheme ensures that metadata producers and consumers continue to evolve sequentially, following versions can depend upon previous ones, and the implementation of new standards is not unnecessarily delayed or even declined. On the other, it requires tools to implement features in the order they happen to be approved and added to the spec, even if a later version is a small but important tightening/loosening of syntax/semantics, while an earlier one is a fairly substantial set of additions and deprecation.
I’m not sure if this is enough of a problem in practice that its worth considering things like adding or switching to a mechanism (bitfield, feature tags, etc) that would allow signalling support for individual features/changes, possibly with periodic rollup version updates (sort of like IEEE 802.11), but I think it might at least be worth discussing the issue and potentially how to address/mitigate this. If so, I can split this off into a new topic for that.