License-File metadata being added to wheel instead of License or License-Expression

[edmorley]

In one project I have the pyproject.toml field project.license specified as "BSD-3-Clause":
https://github.com/heroku/sf-functions-python/blob/a7541831525ae1850ae2c8511d2b0c8f94597a53/pyproject.toml#L10

This adheres to PEP 639, and matches the Hatch docs for license:
https://hatch.pypa.io/latest/config/metadata/#license

However, when performing a hatch build, the resultant wheel's METADATA file:

• Does not include a License or License-Expression attribute (when I would have expected one or the other to be set to a value of BSD-3-Clause).
• Instead, specifies a License-File attribute, which I didn't request via the pyproject.toml config, and such automatic behaviour doesn't appear to be documented in the Hatch docs (I checked https://hatch.pypa.io/latest/config/metadata/#license as well as any other parts of the docs that mentioned the string license)?

This is the contents of the wheel:

$ rg '(Metadata-Version|License)' dist/
dist/salesforce_functions-0.1.0-py3-none-any/salesforce_functions-0.1.0.dist-info/METADATA
1:Metadata-Version: 2.1
7:License-File: LICENSE

dist/salesforce_functions-0.1.0-py3-none-any/salesforce_functions-0.1.0.dist-info/licenses/LICENSE
1:BSD 3-Clause License

This was using Hatch 1.6.3 installed from homebrew, on macOS 12.6 using Python 3.11.0 (also installed via homebrew).

I first thought that #576 would help with this (as it would mean License-Expression would be set), and so tried testing master, by:

1. Installing hatch + hatchling from git revision 6322dab into the current virtual environment.
2. Plus updating the package's build-system.requires to ["hatchling @ git+https://github.com/pypa/hatch.git#subdirectory=backend"]

...however, even after doing that, I see the same behaviour?

Thoughts:

1. If the implicit License-File behaviour is intended (which I presume it might be, given some of the non-mandatory parts of PEP 639), it would be good to document it.
2. It would be great if there were some docs for how to test a non-published version of Hatch/hatchling, since it's quite possible I didn't do so correctly. (Hatch being a build tool + Pip using isolated build environments + Hatch having the sub-dependency on hatchling adds a few complications over a typical "install a single package from Git" workflow.)
3. If I didn't mess up installing from main, then it seems like there might still be a bug here, given that neither License nor License-Expression is set when I specify a license explicitly?

[CAM-Gerlach]

@ofek It appears that unless the grep is not capturing it or I'm missing something, License-Expression is not being set in this user's case. In any case, at least on to Metadata-Version: 2.1, I would suggest that Hatch consider the backwards compatibility provision allowed in the PEP, to output the License-Expression value as License instead/also, since License-Expression is not officially supported on that version. Even if the PEP is accepted tomorrow, the big blocker is most clients still don't support Metadata 2.2, nor 2.3, whereas the PEP would be 2.4.

As for the License-File behavior, it appears to fully follow the current draft of the PEP and the automatic detection and inclusion of files matching LICENSE* (among other globs) LICENSE is fully specified there, and is also the standard behavior of most or all other tools (aside from minor implementation details).

[ofek]

License-Expression is not being set in this user's case. In any case, at least on to Metadata-Version: 2.1

Unreleased #576

output the License-Expression value as License instead/also

I would prefer to not do that

[ofek]

this is finished