While exploring the possibility to add an interface to
prepare_metadata_for_wheel in pypa/build, it was raised that no (as in none at all) PEP 517 backends actually fulfills the promise made in PEP 517:
If the build frontend has previously called
prepare_metadata_for_build_wheeland depends on the wheel resulting from this call to have metadata matching this earlier call, then it should provide the path to the created
.dist-infodirectory as the
metadata_directoryargument. If this argument is provided, then
build_wheelMUST produce a wheel with identical metadata. The directory passed in by the build frontend MUST be identical to the directory created by
prepare_metadata_for_build_wheel, including any unrecognized files it created.
But instead, all major PEP 517 backends choose to ignore
metadata_directory, re-generate metadata from scratch in
build_wheel instead, and make no effort whatsoever to verify the generated metadata is identical.
The issue has been raised to setuptools, flit, and poetry. Poetry devs did not respond to the issue (opened in May 2019). Setuptools actively generates non-identical metadata. Flit is the only project that’s responded. But it does have a point to not make use of the argument—It is easier to always re-generate, and since flit relies solely on static metadata, it does not expect anything to go wrong unless in extreme advanced and niche usages (custom backend extending Flit’s PEP 517 interface), so always verifying the output feels wasting.
So now we have a rule that nobody is following, and people using the interface (frontends and backend extensions) are left in a bad place. How can we improve the situation?