extend twine check

[gaborbernat]

Ran into project https://github.com/jwodder/check-wheel-contents, and made me feel much of those should be done by twine check. Would we be open for this?

The author per jwodder/check-wheel-contents#1 would not mind trying to upstream those.

[di]

I think the author is correct that it might be a bit too opinionated for twine check. The overall goal of twine check is to indicate anything that would prevent twine upload from succeeding.

I think if anything, this should be upstreamed into wheel -- these could be nice warnings to have when building the wheel.

[gaborbernat]

🤔 I don't think it belongs to wheel because it does not depend on setuptools, can be used just as well for flit/poetry that might not use wheel. I guess PyPi will not fail to upload, but might still be not recommended. Maybe it should be separate then 🤔 and perhaps document it here, that check only checks invariants for PyPi and if you want more use x.

[di]

Huh, TIL that flit/poetry don't use wheel to build wheels...

[gaborbernat]

It might at the moment (not 100 on this), but really doesn't have to 🤔 and using wheels only makes sense if you under the hood use setuptools, which flit might do but would be surprised for poetry 🤔

[sigmavirus24]

I think a subset of those could fit into twine check but the tool as a whole is trying to be Flake8 for wheels. Twine handles more than just wheels and so we'd then be starting to bias against linting source distributions and only linting wheels which feels awkward. Twine also owns nothing as far as the build process is concerned (today) and reaching further into the artifacts being uploaded than the metadata (which is required by the PyPI API) seems odd.

[bhrutledge]

@pypa/twine-maintainers What's the resolution for this? Close as out of scope? Duplicate of #430? Other?