Add support for License-Expression parsing (PEP 639)

[cdce8p]

PEP 639 has been (provisionally) accepted recently. hatch added support¹ for it early on and so the first packages which store the license metadata inside the License-Expression field start popping up. E.g. for ftfy it looks like this

...
License-Expression: Apache-2.0
License-File: LICENSE.txt
...

This PR adds the basic parsing support without any validation similar to the existing behavior for the License metadata field or the classifier. It might make sense to add the validation at a later point though.

To keep the changes to a minimum, the behavior of --from=mixed is preserved. However:

Caution

Breaking change: The --from=all output now includes the License-Expression value.

Fixes #225

Footnotes

1. https://hatch.pypa.io/1.9/config/metadata/#spdx-expression ↩

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.14%. Comparing base (3fbf20f) to head (84b2837).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #213   +/-   ##
=======================================
  Coverage   99.13%   99.14%           
=======================================
  Files           1        1           
  Lines         462      466    +4     
=======================================
+ Hits          458      462    +4     
  Misses          4        4           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stefan6419846]

Isn't the proposed handling against PEP 639? According to https://packaging.python.org/en/latest/specifications/core-metadata/#license, the following holds true:

As of Metadata 2.4, License and License-Expression are mutually exclusive. If both are specified, tools which parse metadata will disregard License and PyPI will reject uploads. See PEP 639.

With PyPI not allowing both keys to be set and License-Expression taking precedence otherwise, wouldn't it make more sense to retrieve license-expression as the first variant in METADATA_KEYS["license"]? This would avoid the breaking change as well.

[cdce8p]

With PyPI not allowing both keys to be set and License-Expression taking precedence otherwise, wouldn't it make more sense to retrieve license-expression as the first variant in METADATA_KEYS["license"]?

Yeah, you're correct. License-Expression should take precedence and all other values should be ignored. My initial thought was to preserve backwards compatibility as much as possible and not change the precedence order on an existing option. In practice it shouldn't make much of a difference as "normally" only one should be defined (either License-Expression or License metadata / classifier). Anyway pushed a new commit to update the logic.

This would avoid the breaking change as well.

Not quite sure about that one. The breaking change is in the --from=all output. It adds a new column, so for users who depend on the exact form it's a breaking change.

[SMoraisAnsys]

Thanks for this PR ! Could you update the dependency file to add a package using license expression ? I proposed attrs but any other package doing it is fine :)

[cdce8p]

Could you update the dependency file to add a package using license expression ? I proposed attrs but any other package doing it is fine :)

I'd prefer not to add an additional test dependency just for that. The last prettytable release also added License-Expression. Once #222 is merged, I can update this PR / or do a followup to enable the asserts.

[SMoraisAnsys]

Could you update the dependency file to add a package using license expression ? I proposed attrs but any other package doing it is fine :)

I'd prefer not to add an additional test dependency just for that. The last prettytable release also added License-Expression. Once #222 is merged, I can update this PR / or do a followup to enable the asserts.

Attrs is already a dependency (see the top of the dependency file)
But sure, prettiable is a good target :)

[cdce8p]

Attrs is already a dependency (see the top of the dependency file) But sure, prettiable is a good target :)

It's only a transitive dependency on an old pytest version. Will be removed with #217 it seems. Anyway, I'd like to keep dependency bumps separate. Will update the asserts here, if #217 and / or #222 ever gets merged.

[SMoraisAnsys]

@raimon49 Sorry for the direct ping but this package doesn't seem to have much activity since 6 months. Could you have a look at this PR or should we assume the repo to be dead and move with a fork ?