PEP 639, Round 3: Improving license clarity with better package metadata

Packaging Standards
142

I’ve updated uv publish to set license and license-files in the formdata: Upload: All metadata incl. PEP 639 by konstin · Pull Request #9442 · astral-sh/uv · GitHub. We’re publishing upload test package to test pypi, so e.g. astral-test-token 0.1.1912 should now be a user of the new fields.

uv publish now sets the following multiple use fields. I’m not sure about the pluralization rules, but these seem to work and match warehouse’s test_legacy.py:

  • classifiers
  • dynamic
  • license_file
  • obsoletes_dist
  • platform
  • project_urls
  • provides_dist
  • provides_extra
  • requires_dist
  • requires_external
3 Likes
143

Public service announcement. twine 6.0 has just been released. While this release will not error on distributions using metadata 2.4, it does not send the metadata fields defined in PEP 639 to the package index. On PyPI, this results in the license information not being displayed on the package page.

If you care about correct licensing information being shown on package indexes, you either have to keep using metadata 2.3 or switch to something else to upload your distribution to the indexes. With the recent uv release 0.5.5, uv publish should fully support metadata 2.4.

1 Like
144

Why aren’t the fields submitted? Hatch also supports publishing like UV but twine is more important because that is what the official GitHub Action uses.

2 Likes
145

I am not a twine maintainer. Fully supporting metadata version 2.4 was not deemed important enough to delay the release. AFAICT the focus of the release is to make twine compatible with the latest release of pkginfo, one of its dependencies, that had previously to be pinned to an earlier release causing some trouble for distribution maintainers having to integrate twine in their distribution. Full support for metadata version 2.4 will likely be in the next release.

2 Likes
146

Is this for a project with a dynamic version field that gets determined while building? Metadata 2.2+ disallows a “dynamic” Version field in source distributions, so setuptools caps the metadata version at 2.1 in that case (but still allows inclusion of fields from later metadata versions)

Scratch that, the sdist version info should be static regardless (since the version has to be specified in the filename). So setuptoools not setting the metadata version correctly when adding the new fields sounds like an outright bug.

147

I’m not sure I understand your reply. I have the impression you are confounding the Version and Metadata-Version fields. The latter is what determines the valid metadata fields, but the former is the one recorded in the sdist filename. Regardless, setting the License-File metadata field with Metadata-Version < 2.4 is always invalid.

I’ve reported it to setuptools [BUG] `tool.setuptools.license-files` results in invalid metadata · Issue #4759 · pypa/setuptools · GitHub but because existing tools seem to accept this (and they cannot be made to do stricter validation till srtuptools is not fixed) it is not considered a missing feature and not a bug, thus it will not be fixed untill setuptools gains proper support for metadata version 2.4.

1 Like