metadata version missmatch in uv 0.5.5

[franzhaas]

Dear all,

I got this error when building and uploading my wheel with 0.5.5 to pypi.org.:

Upload failed with status code 400 Bad Request. Server says: 400 license-file introduced in metadata version 2.4, not 2.1. See https://packaging.python.org/specifications/core-metadata for more information.

But it does work for me with 0.5.4.

Accoridng to the release notes, with 0.5.5 uv started to use license-file, however I did not see a mention of moving the metadata version...

Any ideas?

Thanks in advance,
Franz

[konstin]

This is probably #9442: It's correct that you can only use license-file with metadata of at least version 2.4, but we were missing that field in the upload payload previously so pypi's validation didn't work. What build backend are you using?

[franzhaas]

Hi Konstin,

I use.:

[build-system]
requires = ["setuptools", "wheel", "setuptools-scm"]
build-backend = "setuptools.build_meta"

If it helps, the full project is located here.: https://github.com/MarketSquare/robotframework-construct

[FHU-yezi]

I got the same error with uv build used in building my project.

Here is the repo: https://github.com/FHU-yezi/sshared

The failed publish GitHub Action flow: https://github.com/FHU-yezi/sshared/actions/runs/12078435589/job/33682841905

It is a pure Python package and I got this error after updated to the latest uv version.

[konstin]

This is a bug in setuptools: pypa/setuptools#4759

uv unfortunately can't do anything about this.

[franzhaas]

Ok thanks. Any ideas how to have dynamic versioning without setuptools? konsti ***@***.***> schrieb am Fr., 29. Nov. 2024, 11:42:

…

This is a bug in setuptools: pypa/setuptools#4759 <pypa/setuptools#4759> uv unfortunately can't do anything about this. — Reply to this email directly, view it on GitHub <#9513 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXSBILVY5IYIXHUHCKUNST2DBAH5AVCNFSM6AAAAABSVWJU6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBXGU2DGNRZGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[my1e5]

@franzhaas versioningit works with setuptools and also hatchling.

[franzhaas]

I did not try to upload, but when building with hatchling, I ended up using metadata 2.3... for both uv 0.5.4 and 0.5.5...

this might be related to this one.:
pypa/hatch#1819

[SermetPekin]

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

fixed my issue. as @kbrgl suggested

[senges]

If you still want to use setuptools as build backend, a simple workaround is to explicitly provide an empty value for licence-files in your pyproject.toml:

[tool.setuptools]
license-files = []

[hauntsaninja]

Okay, here's what I don't understand...
There is is a setuptools bug, but there's also something funky going on with uv.
I removed all mentions of license from my pyproject.toml and rm -rf build dist; uv build; uv publish gave me the same error. I then did rm -rf build dist; python -m build . ; python -m twine upload dist/* and everything works just fine. What gives?

Does uv build do any caching of metadata somewhere?

[FHU-yezi]

Okay, here's what I don't understand...
Maybe this is a setuptools bug, but there's something funky going on with uv.
I removed all mentions of license from my pyproject.toml and rm -rf build dist; uv build; uv publish gave me the same error. I then did rm -rf build dist; python -m build . ; python -m twine upload dist/* and everything works just fine. What gives?

Does uv build do any caching of metadata somewhere?

Use hatchling instead of setuptools should solve this problem, you can find guide about this in uv documentation.

[hauntsaninja]

Thanks, I understand that's a valid workaround :-) Just based on the sequence of commands I ran, it appears there's also some issue in uv (maybe just a caching issue?) in addition to the one in setuptools

[konstin]

@hauntsaninja:

PEP 639 adds two new fields to the wheel metadata, License-Expression and License-File, with the corresponding pyproject.toml fields license = "..." and license-files = [...]. These fields are added in the new metadata version 2.4.

When uploading a wheel, the uploader reads the METADATA file from the wheel and transforms it to formdata. PyPI has recently started validating the two new metadata fields from PEP 639 in the formdata, thought PyPI does not validate the METADATA. Twine hasn't implemented that PEP yet (pypa/twine#1180), so it does not set the new license fields in the formdata, and PyPI does not catch the invalid metadata (declaring metadata version 2.1 while using version 2.4 fields).

[cdce8p]

When uploading a wheel, the uploader reads the METADATA file from the wheel and transforms it to formdata. PyPI has recently started validating the two new metadata fields from PEP 639 in the formdata, thought PyPI does not validate the METADATA. Twine hasn't implemented that PEP yet (pypa/twine#1180), so it does not set the new license fields in the formdata, and PyPI does not catch the invalid metadata (declaring metadata version 2.1 while using version 2.4 fields).

The twine PR was just merged. It also added a carveout for setuptools to exclude License-File from the metadata if the version is <2.4 as to not break all projects which use setuptools. Maybe this is something which could be added to uv as well? https://github.com/pypa/twine/blob/main/twine/package.py#L225-L234

The setuptools behavior has been in place for so long at this point that it's probably not worth changing until PEP 639 is fully implemented. I've PRs open for that but those depend on some other work which need to happen first and will likely still need some time.

If you still want to use setuptools as build backend, a simple workaround is to explicitly provide an empty value for licence-files in your pyproject.toml:

[tool.setuptools]
license-files = []

Yes, this is a workaround. However, I'd advise against it. It will not only remove the License-File metadata but also the license files from the distribution. You can include them manually via MANIFEST.in but they will still be excluded from the wheel (unless placed inside the project package itself).

The ideal case would really be a workaround added to uv just like in twine.