license metadata is checked but then discarded

[analog-cbarber]

You can put a license in your pyproject.toml and flit will check to make sure it has the correct form, but will then just throw it away rather than include it in the metadata.

https://github.com/pypa/flit/blob/6982faee6f69e21327bdc8cf245fe99d57ea9fc3/flit_core/flit_core/config.py#L469-L493

[takluyver]

I'm waiting for PEP 639 before reworking the options for license metadata. The TODO comment in that code explains why it doesn't put the license from pyproject.toml into the current package metadata format.

[pombredanne]

I am the taking-too-long-to-finish author of PEP639... IMHO you should not wait to include license metadata.

[WolfgangFahl]

I am also interested how this is supposed to work. I tried a work-around in my project like this:

# flit_core.config.ConfigError: license field should be <class 'dict'>, not <class 'str'>
license = { 
  file="LICENSE" 
}

and end up with a garbled result in pypi when using hatchling.

I can't find the "official" way how to do this properly and will need to revert to the plain string version of e.g.

license=Apache-2.0

[takluyver]

I think Hatchling is doing the wrong thing there, though it's not entirely clear, because there isn't really a right thing. It has chosen to read the file and include the full contents as the License field in the package metadata. The metadata spec suggests that the License field is meant for a brief description to identify the license, not the full text.

Part of PEP 639 is to include a new License-File field for this case.

[takluyver]

Oh, and there's also an issue open on PyPI for how it displays really long license fields: https://github.com/pypi/warehouse/issues/12392

[RossComputerGuy]

Is there a solution to this? I get the error described when building Hatchling v1.7.0 with Flit 3.9.0.