tags: floor riscv64 and loongarch64 at glibc 2.17 like every other arch - #43
Merged
Merged
Conversation
…ch (#42) Both architectures were inherited from uv's floor table, which floors them at glibc 2.31 and 2.36 and records no legacy alias for either. Because a target below its floor claims no manylinux tag at all rather than a shortened list, a loongarch64 host on glibc 2.35 was offered 42 tags where pypa/packaging 26.2 computes 582, so no manylinux wheel whatsoever. riscv64 on glibc 2.28 gave 42 against 393. Both now match packaging exactly. Raising the floor alone is not enough: packaging's legacy map is keyed by glibc version alone and is therefore architecture-independent, so manylinux2014_<arch> applies to these architectures too. Direction matters for the consumers. This package answers whether a wheel is installable on the declared target, and the thing that ultimately installs is pip. Being narrower than pip rejects wheels pip would accept, which for a mirror or an offline bundle means silently omitting content the client cannot then obtain. Being wider only costs bytes. Replaces TestLinux_NarrowNonX86Floors, which pinned the old narrow output, with TestLinux_NonX86FloorsAreUniform: a parity assertion against aarch64 that keeps holding as the manylinux series grows, and that fails if any single architecture is re-narrowed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jonyoder
added a commit
that referenced
this pull request
Aug 28, 2026
Dates [Unreleased] as 0.9.0 (2026-08-28) and adds its compare link. CHANGELOG only. A minor bump under the 0.x policy because two changes alter observable behaviour: reqtxt now recognizes --all-releases/--only-final/--use-feature (an unrecognized option was assumed boolean, so its argument became a fabricated requirement), and a standalone --hash line is accepted rather than rejected, matching pip. Contents since v0.8.0: tags manylinux floor fix (#43), marker EvaluateUndecidable/Variables (#47), tags IsCompatibleOrNewer/CompileAnyLibc/Archs (#48), reqtxt Source and pip-parity fixes (#49), dependency bumps (#50).
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.
Closes #42.
riscv64andloongarch64now claim the same manylinux series as every other non-x86 architecture: floored at glibc 2.17, with themanylinux2014_<arch>legacy alias.Both were inherited from uv's floor table, which floors them at 2.31 and 2.36 and records no legacy alias. Because a target below its floor claims no manylinux tag at all rather than a shortened list, that was not marginal:
loongarch64glibc 2.35riscv64glibc 2.28aarch64glibc 2.35 (control)Both figures now match packaging exactly. glibc 2.35 on loongarch64 is a real configuration (Loongnix, Debian), and such a host was previously offered no manylinux wheel at all.
Both causes had to be fixed together. Raising the floor alone leaves the alias missing, because packaging's legacy map is keyed by glibc version alone and is therefore architecture-independent.
Why widen rather than keep uv's numbers
This package answers "is this wheel installable on the declared target", and the thing that ultimately installs is pip, which uses
packaging. Being narrower than pip rejects wheels pip would accept — for a mirror or an offline bundle that means silently omitting content the client then cannot obtain. Being wider only costs bytes. Where the two upstreams disagree, follow the one pip uses.tags/doc.gohas recorded this as a known limitation since the #18766 work, which deliberately left it alone ("deserves its own decision. Tracked for follow-up"). That note and the doc bullet are now removed.Testing
TestLinux_NarrowNonX86Floorsexisted only to pin the narrow output, and is replaced byTestLinux_NonX86FloorsAreUniform— a parity assertion that every non-x86 architecture claims the same manylinux series asaarch64, with the reference itself guarded so a regression there cannot make the comparison vacuous. Written as parity rather than a hardcoded tag list so it keeps holding as the manylinux series grows, and so re-narrowing any single architecture fails it.gofmtclean,go vet ./...clean, full module suite green (including the packaging-generated golden fixtures, which cover the architectures this does not touch).Found while designing PyPI dependency-closure filtering for the Package Manager offline downloader, where a narrower-than-pip tag set is precisely an air-gapped missing-package failure.
🤖 Generated with Claude Code