1.30.0 uses Core-Metadata 2.5 when building, but unsupported by twine

[build-system]
requires = ["hatchling>=1.26,!=1.30.0", "hatch-vcs"]
build-backend = "hatchling.build"

and running build is fine

✨ Pixi task (build in dev): python -m build: (Build SDist and wheel distributions)
* Creating isolated environment: venv+pip...
* Installing packages in isolated environment:
  - hatch-vcs
  - hatchling>=1.26,!=1.30.0
* Getting build dependencies for sdist...
* Building sdist...
* Building wheel from sdist
* Creating isolated environment: venv+pip...
* Installing packages in isolated environment:
  - hatch-vcs
  - hatchling>=1.26,!=1.30.0
* Getting build dependencies for wheel...
* Building wheel...
Successfully built rucio_mcp-0.4.1.dev0+g3c8efeaad.d20260601.tar.gz and rucio_mcp-0.4.1.dev0+g3c8efeaad.d20260601-py3-none-any.whl

✨ Pixi task (build-check in dev): twine check --strict ./dist/*: (Run twine to check)
Checking dist/rucio_mcp-0.4.1.dev0+g3c8efeaad.d20260601-py3-none-any.whl: PASSED
Checking dist/rucio_mcp-0.4.1.dev0+g3c8efeaad.d20260601.tar.gz: PASSED

however, if I pull in the latest (drop the negative selector or just freeze it to 1.30.0), I see the following:

Checking dist/rucio_mcp-0.4.1.dev0+g3c8efeaad.d20260601-py3-none-any.whl: ERROR    InvalidDistribution: Invalid distribution metadata: '2.5' is not a     
         valid metadata version

because twine does not support Core-Metadata: 2.5 at the moment. In the versions I'm using, I have latest twine and latest packaging on python 3.14:

$ pixi run -e dev twine --version
twine version 6.2.0 (keyring: 25.7.0, packaging: 26.2, requests: 2.33.1, requests-toolbelt: 1.0.0,
urllib3: 2.6.3, id: 1.6.1)

It seems this happened in the past when going from 2.3 to 2.4:

You can view this in two CI jobs that just happened to be unlucky time-wise, with a CI job succeeding before the new tag and a CI job failing after the new tag.

The following patch is a stopgap for now, while keeping the new hatchling version

From 337ec62d4953c71ee62605f455bdfe901c27fdac Mon Sep 17 00:00:00 2001
From: Giordon Stark <kratsg@gmail.com>
Date: Mon, 1 Jun 2026 09:15:44 +0800
Subject: [PATCH] patch to drop down to core-metadata 2.4

---
 pyproject.toml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/pyproject.toml b/pyproject.toml
index b222baf..0cabacd 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -64,8 +64,12 @@ docs = [
 version.source = "vcs"
 build.hooks.vcs.version-file = "src/rucio_mcp/_version.py"
 
+[tool.hatch.build.targets.sdist]
+core-metadata-version = "2.4"
+
 [tool.hatch.build.targets.wheel]
 packages = ["src/rucio_mcp"]
+core-metadata-version = "2.4"
 
 [tool.hatch.envs.default]
 dependency-groups = ["dev"]

Thank you for the report. We have yanked 1.30.0

We have reverted the change as well for now to have 2.5 as the default metadata back to 2.4 but will still support users that want 2.5 as the version. Closing this out as we will re-evaluate making the upgrade to 2.5 at a later time

@cjames23

We have reverted the change as well for now to have 2.5 as the default metadata back to 2.4 but will still support users that want 2.5 as the version. Closing this out as we will re-evaluate making the upgrade to 2.5 at a later time

@cjames23 thanks for addressing it and sorry for the noise the feature's created 🙏

@cjames23

@cjames23 can you reopen this again, as this has reared it's head. It seems Metadata 2.5 is being emitted again, but the tooling still doesn't support. I can add the stopgap back in, but I'm worried that I will just forget that I'm on 2.4 when the packaging tools start supporting it.. I don't know the timeline here, but maybe @henryiii knows?

but the tooling still doesn't support

What tooling is that? All tooling I'm aware of has added support for it:

You have to bump something (gh-action-pypi-publish, probably). I really wish there had been a little more time; if someone has a 3-7 day cooldown, and runs updates weekly or monthly, then this hits as a failure. I don't think there was a pressing, rushing update to get this out, and it means I've had to trigger manual Dependabot updates in dozens of repositories.

I'd really recommend waiting at least two months before bumping the metadata version after a twine release for people who lock CI but don't lock the build backend. (I think it's hard to lock build deps generically, like from build-and-inspect-python-package).

@hynek

Also, @hynek chose the worst possible time to drop v3 and v3.0 moving tags; Dependabot will only update to matching tags (by number of dots), so v2 and v2.x tagged actions never get an update since there's no matching tag to update to.

(There's never a good time to do that, to be fair, you are always leaving most of your Dependabot users behind on unsecure old versions doing that.)

Full analysis from Claude Opus 5, it seems I have done 6, and have 28 more to go:

(PS: I didn't check for hatchling specifically, so a few of these are okay because they don't use a backend that bumped the metadata so quickly. But I mostly use hatchling.)

🤖 AI text below 🤖

Answer: 34 live repos — 6 already bumped, 28 still broken

The relevant release is hynek/build-and-inspect-python-package v3.0.1 (2026-07-30): Twine 7, which accepts core metadata 2.5. Note v3 dropped the floating tags — there is no @v3 — so @v2 is now frozen at v2.18.0 and will never get the fix. Every @v2 pin is broken.

Still broken (28 live repos):

Repo	Pin
scikit-build/scikit-build-core	v2.18.0
scientific-python/cookie	v2.18.0
scientific-python/repo-review	v2.18.0
scikit-hep/decaylanguage	v2.18.0
scikit-hep/formulate	v2.18.0
scikit-hep/hist	v2.18.0
scikit-hep/mplhep	v2.18.0
henryiii/check-sdist	v2.18.0
henryiii/flake8-lazy	v2.18.0
scikit-build/{cython-cmake, dynamic-metadata, f2py-cmake, moderncmakedomain}	`@v2`
scikit-hep/{cuda-histogram, fsspec-xrootd, histserv, ragged, uhi, uproot-browser, vector}	`@v2`
pytest-dev/pytest-github-actions-annotate-failures	`@v2`
tomerfiliba/plumbum	`@v2`
scipp-atlas/pyhs3	`@v2`
James11222/glasz	`@v2`
henryiii/{agentic-ai-example, cmake-test-files, flake8-errmsg, validate-pyproject-schema-store}	`@v2`

Already on v3.0.1 (6): pypa/build, pypa/cibuildwheel, pypa/pyproject-metadata, pybind/pybind11_mkdoc, scikit-hep/uproot5, wntrblm/nox.

Excluded: 13 personal forks (henryiii/cookie, henryiii/nox, wheelnext/build, …) and 1 archived repo (scikit-hep/statisfactory).

scientific-python/cookie again matters most — it propagates the @v2 pin into every generated project. scikit-hep is the largest cluster: 11 repos.

chore: secure CI (#99)

@henryiii

What tooling is that? All tooling I'm aware of has added support for it:

I hit this here (https://github.com/kratsg/stare/actions/runs/31656553463/job/94312185774?pr=68). But yes, I'm on v2 of hynek's build and inspect package -- and dependabot didn't catch it for me. I suppose I need to fix that or trigger it. So I'll do what @henryiii and try to get an allrepos to do a bump for hynek/build-and-inspect-python-package@v3.0.1 across my CI files.

I'm using https://github.com/henryiii/skills/tree/main/secure-ci, FWIW. Also tightens up other CI security.

fix: bump hynek/build-and-inspect-python-package to v3.0.1

fix: bump hynek/build-and-inspect-python-package to v3.0.1 (#2)

fix: bump hynek/build-and-inspect-python-package to v3.0.1 (#100)

ci: pin GitHub Actions to SHAs

MNT: Upper bound the `hatchling` version to fix `twine` incompatibility

Also, @hynek chose the worst possible time to drop v3 and v3.0 moving tags; Dependabot will only update to matching tags (by number of dots), so v2 and v2.x tagged actions never get an update since there's no matching tag to update to.

While I'm always very sorry when things break because of me, I'm gonna pose that I've accidentally "chosen" the best-possible time because things broke and there's a chance people noticed and fixed the tags instead of running on 2.x forever. The packaging landscape changed and there's no easy way. :(

Ugh now I worry that folks will start adding an hatchling<1.32 upper bound and a part of the ecosystem will be stuck on old packaging standards cause they'll forget to eventually remove the constraint 😞.

I'm gonna pose that I've accidentally "chosen" the best-possible time because things broke and there's a chance people noticed and fixed the tags instead of running on 2.x forever.

I can't argue with that (given I've opened some 30 or so PRs because of it yesterday). :)

Though that only works on hatchling projects. All other backends won't notice for now.

Reminder: pypa/gh-action-pypi-publish has to be 1.14.2+, just had a failed release in scientific-python/cookie because it was on 1.14.1 still. You won't find that out until after you tag and release.

I'll reiterate I think it was too soon to bump to METADATA 2.5. ;)

MNT: Bump `hynek/build-and-inspect-python-package` to v3.0.1

fix: bump gh-action-pypi-publish to v1.14.2 and drop core-metadata-ve…

MNT: Bump `hynek/build-and-inspect-python-package` to v3.0.1

ci: bump pypa publish action version (#634)

MNT: Bump `hynek/build-and-inspect-python-package` to v3.0.1

fix(build): pin hatchling<1.30 — 1.30+ emits Metadata-Version 2.5 whi…

Navigation Menu

1.30.0 uses Core-Metadata 2.5 when building, but unsupported by twine #2292

Answer: 34 live repos — 6 already bumped, 28 still broken

3 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

1.30.0 uses Core-Metadata 2.5 when building, but unsupported by twine #2292

Description

Activity

kratsg commented on Jun 1, 2026

kratsg commented on Jun 1, 2026

cjames23 commented on Jun 1, 2026

cjames23 commented on Jun 1, 2026

edgarrmondragon commented on Jun 1, 2026

kratsg commented on Aug 13, 2026

edgarrmondragon commented on Aug 13, 2026

henryiii commented on Aug 13, 2026

henryiii commented on Aug 13, 2026

Answer: 34 live repos — 6 already bumped, 28 still broken

kratsg commented on Aug 13, 2026

henryiii commented on Aug 13, 2026

3 remaining items

hynek commented on Aug 14, 2026

edgarrmondragon commented on Aug 14, 2026

henryiii commented on Aug 14, 2026

henryiii commented on Aug 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions