Pypi does not recognize license

[SMoraisAnsys]

Unless there is a delay, it seems that the LICENSE metadata is not available in Pypi for release 24.3.0, see https://pypi.org/project/attrs/24.3.0/

Note that this information was available in 24.2.0, see https://pypi.org/project/attrs/24.2.0/

I suspect the changes from #1377 are the cause for this problem.

[hugovk]

Testing with another package that also uses Hatchling, this is how pyproject.toml was before:

license = { text = "MIT" }
classifiers = [
  "License :: OSI Approved :: MIT License",

The upload shows it had this metadata:

Metadata-Version: 2.4
License: MIT
License-File: LICENSE.txt
Classifier: License :: OSI Approved :: MIT License

PyPI shows:

Unverified details:

• Meta:
  • License: MIT License (MIT)

---

Next, change to:

license = "MIT"
license-files = [ "LICENSE.txt" ]
classifiers = [
  "License :: OSI Approved :: MIT License",

Metadata:

Metadata-Version: 2.4
Name: tinytext
License-Expression: MIT
License-File: LICENSE.txt
Classifier: License :: OSI Approved :: MIT License

PyPI:

Unverified details:

• Meta:
  • License: MIT License

(It changed from "MIT License (MIT)" to "MIT License".)

---

Finally, remove the Trove classifier:

license = "MIT"
license-files = [ "LICENSE.txt" ]

Metadata:

Metadata-Version: 2.4
Name: tinytext
License-Expression: MIT
License-File: LICENSE.txt

PyPI:

Unverified details:

• Meta:
  • [no licence shown]

---

To summarise, the new License-Expression and License-File fields are being added to metadata, but the licence is only shown (as unverified) when using the Trove classifier.

This might be a PyPI bug? Looking at https://pypi.org/pypi/attrs/json I see:

"license": null,
"license_expression": null,
"license_files": null,

So I think the short-term fix for attrs is to keep the Trove classifier (it's only deprecated for now, not removed), and keep the new PEP 639 fields so they can be used when PyPI is ready:

license = "MIT"
license-files = ["LICENSE"]
classifiers = [
  "License :: OSI Approved :: MIT License",

[hugovk]

This might be a PyPI bug?

Or rather twine? Quoting @konstin on the PyPA Discord talking about another issue but with timely relevant info:

... uv publish sets license-file in the formdata (https://github.com/astral-sh/uv/blob/8074917449ec53d238112a9b0722110d902f522e/crates/uv-publish/src/lib.rs#L699) while twine does not (yet) (https://github.com/pypa/twine/blob/75be078d2849d07c3406772cbbdb13c72139b341/twine/package.py#L199)

[konstin]

The warehouse (pypi) side is working, the following test package shows up correctly (https://test.pypi.org/project/astral-test-token/):

[project]
name = "astral-test-token"
version = "0.1.2317"
authors = [{ name = "konstin", email = "[email protected]" }]
classifiers = ["Topic :: Software Development :: Testing"]
dependencies = []
description = "Add your description here"
dynamic = ["gui-scripts", "scripts"]
keywords = ["test", "publish"]
license = "MIT OR Apache-2.0"
license-files = ["LICENSE*"]
maintainers = [{ name = "konstin", email = "[email protected]" }]
optional-dependencies = { "async" = ["anyio>=4,<5"] }
readme = "README.md"
requires-python = ">=3.12"
urls = { "github" = "https://github.com/astral-sh/uv" }

# hatchling should work equally
[build-system]
requires = ["pdm-backend"]
build-backend = "pdm.backend"

[hynek]

According to https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/145 it’s a Twine issue (that is used by the PyPI upload action).

[SMoraisAnsys]

So I think the short-term fix for attrs is to keep the Trove classifier (it's only deprecated for now, not removed), and keep the new PEP 639 fields so they can be used when PyPI is ready:

license = "MIT"
license-files = ["LICENSE"]
classifiers = [
  "License :: OSI Approved :: MIT License",

I like this approach. On top of it, I think that people using pip-licenses (me among others haha) would be able to retrieve the package license with the Trove classifier ! If anyone is interested, this seems to be available with option --from=mixed

[SMoraisAnsys]

Seems like Twine should be able to handle metadata version 2.4 soon (pypa/twine#1180 got merged).

[webknjaz]

So I'll need to bump twine in pypi-publish once it's released.

[martin-traverse]

I hit this issue too. I see there is a PR open, would be great to get a fix merged / released if there is a solution available.

My project has very strict compliance requirements, we had to exclude the latest version of this package for the time being.