Fix license metadata to follow PEP 621

[amyreese]

Description

PEP 621 requires the license field to be a table with either a file or text key: https://peps.python.org/pep-0621/#license

The current value of license = "MIT" is not PEP 621 compliant, even though hatchling allows it.

[amyreese]

I would imagine this is not worthy of a changelog entry?

[github-actions]

diff-shades reports zero changes comparing this PR (16bea05) to main (b60b85b).

---

What is this? | Workflow run | diff-shades documentation

[ichard26]

Good catch! Feel free to add yourself to the AUTHORS list :)

[amyreese]

Fixed formatting and updated authors list. :)

[hynek]

JFTR, a plain SPDX id is part of the hopefully as-good-as-passed PEP 639 that Hatch already implements.

Technically, the new metadata is wrong-ish, because it’s supposed to be the license, not the license ID. That’s not very useful tho (and clutters the PyPI view), so nobody does it (including myself) and hence PEP 639.

All that to say: this should be reverted once PEP 639 passes. ;)

[amyreese]

JFTR, a plain SPDX id is part of the hopefully as-good-as-passed PEP 639 that Hatch already implements.

Neat! When that gets accepted, will PEP621 get updated with the new information, or at least a link to PEP639?

All that to say: this should be reverted once PEP 639 passes. ;)

I agree with this sentiment, however, I originally found this because some of our tooling supporting PEP 621 was broken by this metadata. It would be nice to at least give some amount of time for tooling to catch up to PEP 639 before adopting that new format. 😅

[hynek]

JFTR, a plain SPDX id is part of the hopefully as-good-as-passed PEP 639 that Hatch already implements.

Neat! When that gets accepted, will PEP621 get updated with the new information, or at least a link to PEP639?

One would hope! Currently it does refer to it in nebulous terms:

A practical string value for the license key has been purposefully left out to allow for a future PEP to specify support for SPDX expressions (the same logic applies to any sort of “type” field specifying what license the file or text represents).

All that to say: this should be reverted once PEP 639 passes. ;)
I agree with this sentiment, however, I originally found this because some of our tooling supporting PEP 621 was broken by this metadata. It would be nice to at least give some amount of time for tooling to catch up to PEP 639 before adopting that new format. 😅

Yeah my editor is unhappy too. The Python packaging construction site keeps giving.