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 (1ec35a3).
⚠️ Report is 6 commits behind head on dev-5.5.0.

Additional details and impacted files

@@            Coverage Diff             @@
##           dev-5.5.0     #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.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[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 ?

[martin-traverse]

Hi - any chance of getting something merged for this? Packages are starting to use the new standard. On our project we've started blocking some updates, but that can only be done for so long. Getting a new release onto PyPI that supports the new standard would be really helpful.

[bd-gpasternak]

desperately asking that this get merged so that we don't have to perform surgery to roll our own pip license code.

[johnthagen]

For those in need of this, consider pip-licenses-cli, a maintained fork that is a drop-in replacement that supports PEP 639

• Future of the project #227 (comment)

Previous reviews are sufficiently resolved.

[reactive-firewall]

👍 LGTM;

☑️ PR is approved for dev branch!

@cdce8p Thank you for this PR!