metadata version missmatch in uv 0.5.5 #9513

franzhaas · 2024-11-28T18:47:10Z

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

The text was updated successfully, but these errors were encountered:

konstin · 2024-11-28T19:03:17Z

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 · 2024-11-28T19:06:55Z

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 · 2024-11-29T03:24:42Z

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 · 2024-11-29T10:41:44Z

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

uv unfortunately can't do anything about this.

franzhaas · 2024-11-29T10:49:08Z

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 · 2024-11-29T11:51:17Z

@franzhaas versioningit works with setuptools and also hatchling.

franzhaas · 2024-11-29T19:12:20Z

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

Setuptools is broken (astral-sh/uv#9513)

SermetPekin · 2024-12-02T20:06:09Z

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

fixed my issue. as @kbrgl suggested

Why === Looks like setuptools has some issues with a new pypi restriction: astral-sh/uv#9513. Hatchling does not have these issues. What changed ============ Switch to hatchling Test plan ========= Can we publish?

senges · 2024-12-05T08:09:18Z

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 = []

See astral-sh/uv#9513

see astral-sh/uv#9513

Upload to PyPI failed with setuptools - astral-sh/uv#9513

See pypa/setuptools#4759 and astral-sh/uv#9513.

Ensures we do not run into astral-sh/uv#9513 when publishing.

It should be no longer used since introduction of pyproject.toml, but apparently setuptools still parse it and that brings back issues like astral-sh/uv#9513 which are fixed in pyproject.toml.

hauntsaninja · 2024-12-17T06:50:45Z

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 · 2024-12-17T07:47:56Z

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 · 2024-12-17T07:55:42Z

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 · 2024-12-17T08:25:07Z

@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 · 2024-12-17T12:21:14Z

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.

Set license-files to an empty array to work around issues releasing to PyPI. See: - astral-sh/uv#9513 - pypa/setuptools#4759

See astral-sh/uv#9513

PeriniM · 2025-01-03T12:46:10Z

I had semantic-release set up and suddently it stopped working. The problem was that semrel does not support Metadata v2.4 and therefore the fix was to bump the hatchling version:

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

Error screenshot:

Hope it helps!

The latest 0.75.0 release [failed to publish to PyPi](https://github.com/gabrieldemarmiesse/python-on-whales/actions/runs/12688518269/job/35365228093). This appears to be a [known behavior of setuptools](https://github.com/pypa/setuptools/issues/4759)/[uv](https://github.com/astral-sh/uv/issues/9513) due to a change to supported metadata. This change implements a [suggested workaround](astral-sh/uv#9513 (comment)), and [worked for me when testing](https://github.com/rcwbr/python-on-whales/actions/runs/12713875259/job/35442753576). It appeared to keep the correct license metadata on PyPi, since this field seems to be an optional addition to the `project.license.file` field. Happy to implement any feedback, please lmk!

- Switch setuptools → hatchling as build backend. - Switch setuptools_scm → versioningit as version generator.

- uv requires structured author - needs a workaround for license-file error astral-sh/uv#9513

`uv publish` has not changed for some time, it has [notable production usage](https://github.com/search?q=%22uv+publish%22&type=code) and there are no outstanding blockers, it is time to stabilize it with the 0.6 release. ## Introduction Publishing is only usable through `uv publish`. You need to build source distributions and wheels ahead of time, usually with `uv build`. By default, `uv publish` will upload all source distributions and wheels in the `dist/` folder, ignoring all non-matching filenames. By default, `uv build` and most other build frontend write their artifacts to `dist/`. Together, we can build a publish workflow including a smoke test that all relevant files have actually been included in the wheel: ``` uv build uv venv uv pip install --find-links dist ... uv run smoke_test.py uv publish ``` ## Project configuration There are 3 options supported in configuration files: - `tool.uv.publish-url` - `tool.uv.trusted-publishing` - `tool.uv.check-url` ## Index configuration Options support on the CLI and through environment variables for index configuration: ``` --index <INDEX> The name of an index in the configuration to use for publishing [env: UV_PUBLISH_INDEX=] --publish-url <PUBLISH_URL> The URL of the upload endpoint (not the index URL) [env: UV_PUBLISH_URL=] --check-url <CHECK_URL> Check an index URL for existing files to skip duplicate uploads [env: UV_PUBLISH_CHECK_URL=] ``` There are two ways to configure `uv publish`: Passing options individually or using the index API. For the individual options, there `--publish-url` and `--check-url`, and their configuration counterparts, `tool.uv.publish_url` and `tool.uv.check_url`. `--publish-url` is named this way to be clearly different from the simple index URL, since uploading to the index URL leads to unclear errors, or worse a . While we intend to keep supporting this configuration, the index API is better integrated. In the index API, the user specifies `[[tool.uv.index]]`, with an index name, the simple index URL and the publish URL. The `publish-url` and `url` are equivalent to `--publish-url` and `--check-url`. The `url` being mandatory makes for a better upload behavior (next paragraph). ```toml [[tool.uv.index]] name = "pypi" url = "https://pypi.org/simple" publish-url = "https://upload.pypi.org/legacy/" ``` ## Existing files and API limitations A version of a package contains multiple files, for pure-python packages usually a source distribution and a wheel, for native packages usually many, larger wheels and a source distributions. Uploads in the not officially specified Upload API 1.0 are file based: Once you upload a file, the version is created, even though most files are still missing. When uploading a series of files fails in the middle (e.g. the CI server breaks), the release is only half uploaded. For such cases, you want to re-try the upload. The response of an index when re-uploading a file is implementation defined. Notably, PyPI accepts uploads of the same file again with status 200, but rejects uploads of a file with the same name but different contents with status 400. Other indexes reject all attempts at re-uploads with different status codes and messages. Twine handles this with `--skip-existing`, which allows ignoring errors due to files with the same name as an existing file being uploaded, however this does also not error when uploading a file with different contents but the same name, which indicates a problem with the publish pipeline. To properly solve this, we need the ability to stage releases: Files of a version are uploaded to a staging area, and only when all files are uploaded, we atomically publish the release. When an upload breaks or CI fails, we can discard or overwrite the staging area and try again. This will only be properly solved by PEP 694 "Upload 2.0 API for Python Package Indexes", with unclear progress. For local publishing, it would also be convenient to be able to check which files exist and what their hashes are from only the publish URL, so files in the `dist/` folder from a previous release can be ignored. In the Upload API 1.0, we need to upload transformed METADATA fields along with the file as form-data. We currently upload only recognized metadata fields, where we know how to translate the field name to the form-data name. This means when a user adds unknown, wrong or future-PEP metadata we miss it. To me best knowledge no index currently verifies that the form-data and the METADATA file in the wheel match. Upload API 2.0 will be an entirely new protocol. It is unclear how we will decide whether to use Upload API 1.0 or Upload API 2.0 once the latter is released. Upload API 2.0 will remove the need for a check URL. This means no changes for `--index`, but `--check-url` will be incompatible with Upload API 2.0. ## Authentication Options support on the CLI and through environment variables for authentication: ``` -u, --username <USERNAME> The username for the upload [env: UV_PUBLISH_USERNAME=] -p, --password <PASSWORD> The password for the upload [env: UV_PUBLISH_PASSWORD=] -t, --token <TOKEN> The token for the upload [env: UV_PUBLISH_TOKEN=] --trusted-publishing <TRUSTED_PUBLISHING> Configure using trusted publishing through GitHub Actions [possible values: automatic, always, never] --keyring-provider <KEYRING_PROVIDER> Attempt to use `keyring` for authentication for remote requirements files [env: UV_KEYRING_PROVIDER=] [possible values: disabled, subprocess] ``` We need credentials for the publish URL, and we may need credentials for the check URL. We support credentials from environment variables, the CLI, the URL, the keyring, trusted publishing or a prompt. The username can come from, in order: - Mutually exclusive: - `--username` or `UV_PUBLISH_USERNAME`. The CLI option overrides the environment variable - The username field in the publish URL - If `--token` or `UV_PUBLISH_TOKEN` are used, it is `__token__`. The CLI option overrides the environment variable - If trusted publishing is available, it is `__token__` - (We currently do not read the username from the keyring) - If stderr is a tty, prompt the user The password can come from, in order: - Mutually exclusive: - `--password` or `UV_PUBLISH_PASSWORD`. The CLI option overrides the environment variable - The password field in the publish URL - If `--token` or `UV_PUBLISH_TOKEN` are used, it is the token value. The CLI option overrides the environment variable - If the keyring is enabled, the keyring entry for the URL and username - If trusted publishing is available, the trusted publishing token - If stderr is a tty, prompt the user If no credentials are found, we do a final check in the auth middleware cache and otherwise error without sending the request. Trusted publishing is only supported in GitHub Actions. By default, we try to retrieve a token from it in GitHub Actions (`GITHUB_ACTIONS` is `true`) but continue even it this fails. Trusted publishing can be forced with `--trusted-publishing always`, to error on misconfiguration, or deactivated with `--trusted-publishing never`. The option can also be configured through `tool.uv.trusted-publishing`. When `--check-url` or `--index` are used, we may need credentials for the index URL, too. These are handle separately by the same rules as using the index anywhere else. The `--keyring-provier` option is however shared between them, turning the keyring on for either turns it on for both. As future option, we could read `UV_INDEX_USERNAME` and `UV_INDEX_PASSWORD` as fallbacks for the publish credentials (#9845). This however would clash with prompting: When index credentials and upload credentials are not the same (they usually should be different, since regular uv operations should have less privileges than publish), we would then instead of prompting use the wrong credentials from `UV_INDEX_*` and fail. A major UX problem is that there is no standard for the username when using a token (or rather, there is no standard for just sending a token without a username). PyPI uses `__token__`, Cloudsmith used to use your username or `token`, but now also supports `__token__` (#8221), while Google Cloud Artifacts always uses `oauth2accesstoken` (#9778). This means the index documentation may say you're getting a token for authentication, but you must not use `--token`, you must instead set username and password. This is something that we can hopefully fix with Upload API 2.0. An unsolved problem with the keyring is that you it's best practice to use publish tokens scoped to projects and store tokens in a secure location such as the keyring, but the keyring saves a single password per publish URL and username combination. That means that it can't natively store separate passwords for publishing multiple packages. The current hack around this is using the package name as query parameter, e.g. `https://test.pypi.org/legacy/?astral-test-keyring`, as PyPI ignores this query parameter. This is however only applicable when publishing locally and not from CI. Another problem is that the keyring implementation currently relies on the `keyring` pypi package, which needs to be installed in PATH together with its plugins and is comparatively slow. This would be improved by native keyring support (#10867), with the same caveats such as keyring plugins that shared with the simple index API. ## Missing and unsupported features We currently don't upload attestations (PEP 740). Attestations are an additional field in the form-data, so we should be able to add them transparently without any changes to the API, unless we want to add a switch to deactivate even when trusted publishing is used. See also https://trailofbits.github.io/are-we-pep740-yet/. Setuptools is writing an invalid combination of Metadata-Version and used metadata fields in some cases, which PyPI correctly rejects (#9513). We set a 15min overall timeout since reqwest is missing a write timeout option (seanmonstar/reqwest#2403). #8641 and #8774: We build artifact checking in some capacity. This should be done ideally by the build backend or at latest as part of `uv build`, doing it as part of publish is too late.

konstin added the upstream An upstream dependency is involved label Nov 29, 2024

yehoshuadimarsky mentioned this issue Dec 2, 2024

Can't publish to PyPI because of error with license-file yehoshuadimarsky/bcpandas#219

Closed

kbrgl added a commit to cartesia-ai/cartesia-python that referenced this issue Dec 2, 2024

Use hatchling for building

8613c35

Setuptools is broken (astral-sh/uv#9513)

blast-hardcheese mentioned this issue Dec 4, 2024

Address incorrect packaging information replit/river-python#130

Merged

thomascellerier added a commit to thomascellerier/aiortnetlink that referenced this issue Dec 6, 2024

Use hatchling instead of setuptools to build package

3159a14

See astral-sh/uv#9513

MatyiFKBT added a commit to MatyiFKBT/PySteamMarket that referenced this issue Dec 6, 2024

ci(build): use hatchling

d0690dc

see astral-sh/uv#9513

acarapetis added a commit to acarapetis/sqlakeyset that referenced this issue Dec 7, 2024

Switch build system to hatchling

499a1f8

Upload to PyPI failed with setuptools - astral-sh/uv#9513

nijel added a commit to WeblateOrg/wllegal that referenced this issue Dec 16, 2024

fix: add workaround for setuptools bug

a4c7bb5

See pypa/setuptools#4759 and astral-sh/uv#9513.

nijel added a commit to WeblateOrg/language-data that referenced this issue Dec 16, 2024

fix: add workaround for setuptools bug

4abc1cc

See pypa/setuptools#4759 and astral-sh/uv#9513.

nijel added a commit to WeblateOrg/weblate that referenced this issue Dec 16, 2024

chore: wipe license-files for setuptools

1ea1b73

Ensures we do not run into astral-sh/uv#9513 when publishing.

hauntsaninja mentioned this issue Dec 17, 2024

[BUG] tool.setuptools.license-files results in invalid metadata pypa/setuptools#4759

Open

tpgillam mentioned this issue Dec 19, 2024

Workaround pypa/setuptools#4759 tpgillam/mt2#71

Merged

akrabat added a commit to akrabat/rst2pdf that referenced this issue Dec 24, 2024

Workaround pypa/setuptools#4759

68e6576

Set license-files to an empty array to work around issues releasing to PyPI. See: - astral-sh/uv#9513 - pypa/setuptools#4759

akrabat added a commit to akrabat/rst2pdf that referenced this issue Dec 24, 2024

Workaround pypa/setuptools#4759

e15dee4

Set license-files to an empty array to work around issues releasing to PyPI. See: - astral-sh/uv#9513 - pypa/setuptools#4759

akrabat mentioned this issue Dec 24, 2024

Workaround pypa/setuptools#4759 rst2pdf/rst2pdf#1257

Merged

StuartMacKay added a commit to StuartMacKay/ebird-checklists that referenced this issue Dec 28, 2024

fix: Correct issue with PyPI validation

5fef23a

See astral-sh/uv#9513

lucach added a commit to LuCEresearchlab/pytamaro that referenced this issue Jan 9, 2025

Workaround for astral-sh/uv#9513

eabccb4

rcwbr mentioned this issue Jan 10, 2025

Work around setuptools license file metadata issue gabrieldemarmiesse/python-on-whales#666

Merged

khaeru added a commit to khaeru/sdmx that referenced this issue Jan 13, 2025

Work around astral-sh/uv#9513 / pypa/setuptools#4759

fdb6f24

khaeru added a commit to khaeru/sdmx that referenced this issue Jan 13, 2025

Work around astral-sh/uv#9513 / pypa/setuptools#4759

54f9035

- Switch setuptools → hatchling as build backend. - Switch setuptools_scm → versioningit as version generator.

khaeru added a commit to khaeru/sdmx that referenced this issue Jan 13, 2025

Work around astral-sh/uv#9513 / pypa/setuptools#4759

59d267f

- Switch setuptools → hatchling as build backend. - Switch setuptools_scm → versioningit as version generator.

khaeru added a commit to khaeru/sdmx that referenced this issue Jan 13, 2025

Work around astral-sh/uv#9513 / pypa/setuptools#4759

8608f0d

- Switch setuptools → hatchling as build backend. - Switch setuptools_scm → versioningit as version generator.

khaeru added a commit to khaeru/sdmx that referenced this issue Jan 13, 2025

Work around astral-sh/uv#9513 / pypa/setuptools#4759

095056c

- Switch setuptools → hatchling as build backend. - Switch setuptools_scm → versioningit as version generator.

khaeru added a commit to khaeru/dsss that referenced this issue Jan 14, 2025

Work around astral-sh/uv#9513 / pypa/setuptools#4759

5dc21df

- Switch setuptools → hatchling as build backend. - Switch setuptools_scm → versioningit as version generator.

khaeru mentioned this issue Jan 16, 2025

Update code quality configuration iiasa/ixmp#555

Merged

3 tasks

rmorshea mentioned this issue Jan 17, 2025

fix build-system rmorshea/python-copier-template#16

Merged

CaptSolo mentioned this issue Jan 18, 2025

uv publish error uploading to test.pypi.org due to metadata version mismatch #10733

Closed

blais mentioned this issue Jan 26, 2025

Use PEP 621 compliant pyproject.toml beancount/beangrow#38

Merged

blais added a commit to beancount/beangrow that referenced this issue Jan 26, 2025

Fixed pyproject.toml for release

4c740c4

- uv requires structured author - needs a workaround for license-file error astral-sh/uv#9513

konstin mentioned this issue Jan 28, 2025

Promote uv publish from preview to stable #7839

Open

19 tasks

konstin mentioned this issue Jan 28, 2025

Stabilize uv publish #11032

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

metadata version missmatch in uv 0.5.5 #9513

metadata version missmatch in uv 0.5.5 #9513

franzhaas commented Nov 28, 2024 •

edited

Loading

konstin commented Nov 28, 2024

franzhaas commented Nov 28, 2024 •

edited

Loading

FHU-yezi commented Nov 29, 2024

konstin commented Nov 29, 2024

franzhaas commented Nov 29, 2024 via email

my1e5 commented Nov 29, 2024

franzhaas commented Nov 29, 2024

SermetPekin commented Dec 2, 2024

senges commented Dec 5, 2024 •

edited

Loading

hauntsaninja commented Dec 17, 2024 •

edited

Loading

FHU-yezi commented Dec 17, 2024

hauntsaninja commented Dec 17, 2024 •

edited

Loading

konstin commented Dec 17, 2024 •

edited

Loading

cdce8p commented Dec 17, 2024

PeriniM commented Jan 3, 2025

metadata version missmatch in uv 0.5.5 #9513

metadata version missmatch in uv 0.5.5 #9513

Comments

franzhaas commented Nov 28, 2024 • edited Loading

konstin commented Nov 28, 2024

franzhaas commented Nov 28, 2024 • edited Loading

FHU-yezi commented Nov 29, 2024

konstin commented Nov 29, 2024

franzhaas commented Nov 29, 2024 via email

my1e5 commented Nov 29, 2024

franzhaas commented Nov 29, 2024

SermetPekin commented Dec 2, 2024

senges commented Dec 5, 2024 • edited Loading

hauntsaninja commented Dec 17, 2024 • edited Loading

FHU-yezi commented Dec 17, 2024

hauntsaninja commented Dec 17, 2024 • edited Loading

konstin commented Dec 17, 2024 • edited Loading

cdce8p commented Dec 17, 2024

PeriniM commented Jan 3, 2025

franzhaas commented Nov 28, 2024 •

edited

Loading

franzhaas commented Nov 28, 2024 •

edited

Loading

senges commented Dec 5, 2024 •

edited

Loading

hauntsaninja commented Dec 17, 2024 •

edited

Loading

hauntsaninja commented Dec 17, 2024 •

edited

Loading

konstin commented Dec 17, 2024 •

edited

Loading