Detect and repair (if possible) `.dist-info/WHEEL` contents?

[woodruffw]

Hi there! I'm opening this for consideration.

For better or worse, some people like to manually patch their wheels after they're built by a normal, well-behaved build backend. Sometimes this means that they modify their wheel tags without updating the corresponds Tag: fields in .dist-info/WHEEL, or update those fields incorrectly (e.g. by doing Tag: <compressed-tag> instead of one Tag: per expanded compatibility tag.

It'd be great if auditwheel could detail these (and repair them, where possible) 🙂

For reference, I've made some misshapen wheels that exhibit these behaviors:

• futzed_dist_info_wheel_tag_invalid-0.1.0-py3-none-any.whl demonstrates a tag inconsistency/invalidity (valid tags in the filename, but the Tag: in the WHEEL file is junk)
• futzed_dist_info_wheel_tag_missing-0.1.0-py3-none-any.whl demonstrates the Tag: being missing entirely from the WHEEL file

(More broadly, these and others are all detected by a consistency check between the wheel filename's expanded tags and the Tag: set.)

I think there are other potential consistency checks as well (e.g. on Build and Root-Is-Purelib).

CC @konstin for viz

[konstin]

I compiled a list of those mishaps, including the ziglang and torch packages, in pypi/warehouse#19411.

[mayeut]

Relates somewhat to #642
Contributions welcomed.

[mayeut]

Is there at least a validation function in pypa/packaging ?
Given pypi/warehouse#19411 implements one, I'd say there isn't one and, IMHO, one should be implemented so that it could be reused at least in the PyPA ecosystem (warehouse, pip, twine, auditwheel, ...) even though all those projects are independent from one another in terms of dev/governance.
All those exemple PyPA projects already depend on pypa/packaging.