add license check to twine check

[samuelcolvin]

I (and others) have released a few packages recently with the full text of the license file in the License: key of PGK-INFO.

Examples:

• https://pypi.org/project/arq/0.24.0/
• https://pypi.org/project/dnserver/0.2.1/
• https://pypi.org/project/hatch-fancy-pypi-readme/22.4.0/

This is caused by a mistake in pyproject.toml -> [project]: erroneously had license = { file = 'LICENSE' }, when it should have license = { text = 'MIT' }.

Anyway, the point is, it would be great if twine check could check this key and raise an error when the License field is too long, or otherwise not a valid value.

See pydantic/pydantic#4520 (comment) for some more context.

[bhrutledge]

TL;DR: I think there's some ambiguity on how to use the license property, and I don't think Twine is the right place to check it.

According to the project metadata specification:

The file key has a string value that is a file path relative to pyproject.toml to the file which contains the license for the project. The text key has a string value which is the license of the project.

The definition of text is ambiguous to me; "the license of the project" could be read as the "content of the license of the project". PEP 621 seems to confirm this interpretation:

The text key has a string value which is the license of the project whose meaning is that of the License field from the core metadata.

Where License is defined as:

Text indicating the license covering the distribution where the license is not a selection from the “License” Trove classifiers.

Combined with a vague recollection that PyPI will use classifiers for the "Meta > License" content, I think the preferred approach for MIT would be to add License :: OSI Approved :: MIT License to classifiers, and not use license at all.
@di or @dstufft, can you confirm this from Warehouse's perspective?

It's worth noting that how a license is specified is likely to change with PEP 639 (currently a draft), which includes an appendix that notes the current inconsistencies.

With all of this in mind, I don't think Twine can or should be opinionated here.

Furthermore, there have been a lot of proposals to add functionality to twine check, but the current scope of that command is simply to make sure that the package renders properly on PyPI. I proposed a framework for folks to write their own checkers, but there was never a consensus on that.

[samuelcolvin]

I think that's very fair, thanks so much for the detailed response.

Closing this for sake of tidiness.