Partially dynamic project metadata proposal (pre-PEP)

[oscarbenjamin]

@pf_moore

If a field is not marked as dynamic in a sdist, the spec clearly says “then the value of the field in any wheel built from the sdist MUST match the value in the sdist”. When I wrote PEP 643, I didn’t even consider the possibility of tools reading an existing wheel and amending its metadata.

The metadata is static from the perspective of any build frontend. Unfortunately a naive build frontend produces binaries that can be used locally but must be “repaired” to be suitable for PyPI. The fact that PyPI can distribute binaries at all depends in large part on tools like auditwheel that do this.

@pf_moore

Of course, if you need auditwheel to build a usable wheel for a package, I’m not sure what anyone would be doing installing from sdist

Plenty of people still build/install from sdist. It just requires installing the non-Python dependencies and toolchain first. Also every redistributor like conda builds from the sdist but they don’t do the bundling which is only needed for PyPI. From their perspective the metadata is static.

The question is whether static vs dynamic refers to the wheel that pops out of a PEP 517 build or to the relationship between the sdist and the wheels on PyPI. Those two things are not the same because of e.g. auditwheel.