tags: accept newer platforms than declared, any-libc linux targets, exported arch lists

[jonyoder]

Addresses #45, items 1-3. Item 4 is withdrawn — see below.

Three additive changes to tags, one commit each.

Matcher.IsCompatibleOrNewer (the one that earns its keep)

The platform walks run downward from the declared version to a floor, so a Matcher answers "can the host I described run this wheel". A mirror or an offline bundle asks whether a durable declaration of that host should collect the wheel, and the two diverge over time: a set compiled once quietly stops matching wheels built for platforms released since. Accepting a too-new platform costs bytes; rejecting one costs availability, and for an air-gapped mirror a wheel not collected cannot be obtained at all.

Consumers currently work around this by baking their own libc and macOS constants and adding a drift test that goes red whenever PyPI publishes a new platform tag — a test that fails for reasons unrelated to whatever change is under review. This removes the need for all three.

The interpreter and ABI axes are not relaxed. Matcher now retains the set of (Interpreter, ABI) pairs it accepts on any platform, and a candidate qualifies as newer only if its pair is already in that set. Without it a cp314 wheel would ride in on a newer platform tag. Covered for the plain case and for the abi3/abi3t substitution, where a free-threaded target must not gain abi3 wheels at any platform version.

No rank is returned, deliberately: these tags fall outside the ordered set the Matcher generated, so there is no defensible priority.

parseMacosPlatformTag is new, since distro.go's parseLibcPlatformTag has no macOS counterpart. It is tested against the macosx_10_9_x86_64 shape that defeats a naive _x86_64 suffix test.

Two things the tests corrected while writing this, both worth a reviewer's eye:

• Legacy aliases are judged by the glibc version they name, not by being old. manylinux2014 is newer than a 2.12 declaration and merely compatible with a 2.28 one. I asserted the opposite first; the rule is "requires more platform than declared", not "is recent".
• muslMajor/muslMinor are stored separately from target.LibcMajor/Minor. My first version reused them and a test failed: comparing musllinux_2_0 against a glibc 2.28 floor reads as "older" and rejects the wheel. musl and glibc version numbers have no correspondence.

Target.CompileAnyLibc

Compile requires a Libc and platform tags are manylinux xor musllinux depending on it, so "linux x86_64, either libc" meant compiling two targets and unioning them by hand. Omitting the musl one is silent: every musllinux wheel stops matching with nothing to indicate a whole family was dropped. TestCompileAnyLibc_SingleFamilyDropsTheOther pins that failure so the helper's value is executable rather than argued.

The union is deduplicated, because the overlap is real: the bare linux_<arch> tag and the entire compatible tier are emitted by both families. glibcToMusl does not invent a glibc/musl correspondence; it returns the newest musl version this package generates, because musllinux tags are floors so the newest value accepts the widest set. A caller needing an exact musl floor should compile that target itself, and the doc says so.

Archs(os) and OSes()

Previously package-private, so a caller validating an operator-supplied os/arch string could reject a value but not report what it would have accepted, and generated documentation could not derive from the source of truth. The spellings are neither uniform nor guessable: windows uses amd64 where linux uses x86_64, macOS uses arm64 where linux uses aarch64.

Returns copies. TestArchs_ReturnsACopy pins that a caller cannot widen what Compile accepts, and TestArchs_AgreesWithValidate pins the property that motivates exporting at all: every arch reported compiles, and a value not reported does not.

Item 4 withdrawn: PyPy targets without an implementation version

The issue proposed rejecting Implementation: "pp" with no ImplMajor/ImplMinor, on the grounds that such a target silently collects no PyPy extension wheels.

I implemented it and three tests failed, one of them TestGolden/pp310_noabi_windows_amd64.json — a fixture generated by testdata/gen_goldens.py from pypa/packaging, recording that packaging produces exactly pp310-none-win_amd64 plus the compatible tier for that input. So the current behaviour is faithful to packaging, documented in Target's own doc comment, and pinned by both that fixture and TestPyPy_UnknownImplVersion.

Rejecting the input would therefore be a deliberate divergence from packaging and would delete a golden fixture, which is the opposite of this package's design posture. The behaviour is correct; the hazard belongs to the consumer, which should require an implementation version in its own declaration syntax rather than passing an under-specified target. Reverted, and I'll note it on the issue.

Verification

gofmt clean, go vet ./... clean, full module suite green including the packaging-generated golden fixtures.

🤖 Generated with Claude Code