🔧 build: cap hatchling <1.30 so pkg_meta produces publishable metadata#591
Merged
Merged
Conversation
hatchling 1.30.0 began emitting Metadata-Version 2.5 (PEP 794) in built wheels and sdists. The pinned twine floor (twine>=5.1.1, resolving to the latest released twine 6.2.0) hardcodes its accepted metadata versions up to 2.4 and rejects 2.5, so `twine check` aborts with "'2.5' is not a valid metadata version". No released twine accepts metadata 2.5 yet (support exists only on twine git main, unreleased), so bumping the twine floor is not viable. Instead cap the build backend to hatchling>=1.27,<1.30, which emits metadata 2.4 that released twine accepts. This keeps the build sound until twine ships metadata 2.5 support, and unblocks the pkg_meta CI gate repo-wide.
63597de to
1d3e56f
Compare
gaborbernat
added a commit
that referenced
this pull request
Jun 1, 2026
Follow-up to #591. That PR capped `hatchling<1.30` because 1.30 emitted Metadata-Version 2.5 (PEP 794), which no released twine and PyPI accept yet. hatchling 1.30.0 has since been **yanked** from PyPI, with the yank reason: *"the default core metadata version was increased to 2.5 and some major projects like twine do not yet support it."* pip and uv skip yanked releases during resolution, so the build now lands on 1.29.0 (Metadata-Version 2.4) without any upper bound. ⏪ The explicit cap is therefore redundant. Dropping it back to `hatchling>=1.27` keeps us forward compatible: the full chain to publishing 2.5 needs a twine release (pypa/twine#1317), then a pypa/gh-action-pypi-publish release, then dependabot bumping the pinned publish action — once that lands, a future unyanked hatchling can emit 2.5 without another pyproject edit. Verified locally: with no cap the build resolves to hatchling 1.29.0, emits Metadata-Version 2.4, and `tox -e pkg_meta` passes (uv build + twine check + check-wheel-contents). Refs: - #591 — the cap this reverts - pypa/twine#1317 — removes the validator monkeypatch (merged, unreleased) - pypi/warehouse#19083 — PyPI support for Metadata 2.5 (open)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
pkg_metaCI environment started failing on every branch with:hatchling 1.30.0 began emitting
Metadata-Version: 2.5(PEP 794, addingImport-Name/Import-Namespace), and[build-system].requirespinned onlyhatchling>=1.27, so fresh CI resolved to 1.30. 🔧 The problem is not just the checker: metadata 2.5 cannot actually be published today.packaging's validator to a hardcoded list ending at 2.4, sotwine checkrejects 2.5. The monkeypatch was removed in Remove monkeypatch allowing Metadata 2.0 pypa/twine#1317, but that is unreleased — there is no twine release that accepts 2.5, so bumping thetwine>=floor is not an option.Import-Name,Import-Namespace) pypi/warehouse#19083 is still open; warehouse supports up to 2.4.So a 2.5 wheel is unpublishable regardless of the checker, and
pkg_meta's red is correct signal. The minimal fix that keeps the package genuinely publishable is to cap the build backend just below the version that introduced 2.5:This produces Metadata-Version 2.4, which both released twine and PyPI accept. Verified
tox -e pkg_metagoes green (uv build + twine check + check-wheel-contents). ⏳ A comment inpyproject.tomlmarks this as removable once twine ships pypa/twine#1317 and PyPI implements pypi/warehouse#19083 — at which point the cap should drop and thetwine>=floor bump instead.Refs:
Import-Name,Import-Namespace) pypi/warehouse#19083 — PyPI support for Metadata 2.5 (open)