Correct formatting of pyproject.toml's license field.

[gsmecher]

Current setuptools documentation uses the following example:

license = {text = "BSD 3-Clause License"}

Fixes #117.

[Julian]

The setuptools documentation isn't really relevant (we're not using setuptools, we use hatch as the build tool here).

But this behavior is covered by the packaging specs -- so what is relevant is the latest relevant PEP here, which I think is PEP 639. It contains an example exactly like what we have:

Or, in the [project] table of pyproject.toml:

[project]
license = "MIT"

which, combined with @ofek's comment here who's an expert :) makes me think this is correct as-is, but let's see what the other folks have to say.

[gsmecher]

Thanks, @Julian - I didn't notice the earlier issue (#104).

PEP 621 also supports a table rather than a string. I will admit to being confused by the overlapping systems here.

[Julian]

My guess is that 621 is being expanded by 639 (the field is being redefined to take extra types), and hatch already supports 639 (even though it's still a draft), so we use it.

But I didn't plow through reading the PEPs myself at the minute.

[gsmecher]

PEP 639 states:

Table values for the license key in the [project] table, including the text and file table subkeys, are now deprecated. If the new license-files key is present, build tools MUST raise an error if the license key is defined and has a value other than a single top-level string.
If the new license-files key is not present and the text subkey is present in a license table, tools SHOULD issue a warning informing users it is deprecated and recommending a license expression as a top-level string key instead.
Likewise, if the new license-files key is not present and the file subkey is present in the license table, tools SHOULD issue a warning informing users it is deprecated and recommending the license-files key instead.
If the specified license file is present in the source tree, build tools SHOULD use it to fill the License-File field in the core metadata, and MUST include the specified file as if it were specified in a license-file.paths field. If the file does not exist at the specified path, tools MUST raise an informative error as previously specified. However, tools MUST also still assume the specified default value for the license-files key and also include, in addition to a license file specified under the license.file subkey, any license files that match the specified list of patterns.

It looks like you're already in good shape, and this PR would be a regression. Carry on!