What does the platform tag manylinux_2_28_x86_64 on a wheel promise, and which hosts can install it?

## The problem the tag solves A compiled extension is linked against a C library. Linux has no single ABI you can name in a filename the way `win_amd64` names one, because "Linux" is dozens of distributions with different glibc versions and different library sets. A tag of plain `linux_x86_64` is therefore meaningless as a compatibility promise — an installer cannot know whether such a file will load — and index servers reject it for exactly that reason. `manylinux` is the agreed answer: instead of naming a distribution, name a **baseline**. A wheel tagged `manylinux_2_28_x86_64` asserts two things. First, it was built against glibc 2.28, so it will load on any host whose glibc is 2.28 or newer, since glibc keeps backward compatibility forward in time. Second, it links only against a short allowlist of libraries that essentially every distribution ships (the C library and a handful of core system libraries); anything else the extension needs was vendored into the archive when the wheel was built. That pair is what makes one file work across distributions the author never tested on. ## Reading the number The modern, perennial spelling is `manylinux_{major}_{minor}_{arch}` — glibc version, then architecture. The earlier fixed names map onto it: `manylinux1` is glibc 2.5, `manylinux2010` is 2.12, `manylinux2014` is 2.17. Because they are aliases rather than a different scheme, published files frequently carry both spellings in one dotted field, so that installers old enough to know only the fixed names still see a match. Higher numbers mean *newer* toolchains and *narrower* reach. A project choosing `manylinux_2_28` gets a modern compiler and modern language features; a project staying at `manylinux_2_17` still supports very old long-term-support hosts. That choice is the whole tradeoff on the publishing side. ## Which hosts match The tag is a floor, not an equality test. A host with glibc 2.39 installs a `manylinux_2_17` wheel happily. A host with glibc 2.17 does **not** install a `manylinux_2_28` wheel: the constraint runs one way only. Three misses are worth naming explicitly: - **Too old.** A long-lived base image pinned years ago will fail the newer baseline. This is the classic "it works on my laptop" split. - **Wrong C library.** musl-based images are not glibc at all, so no `manylinux` tag ever matches them; they require `musllinux_1_2_*` wheels, which many projects still do not publish. - **Wrong architecture.** `x86_64` and `aarch64` wheels are separate files; a project can publish one and not the other. In each case the installer does not error — it silently falls back to the source distribution and compiles, which is how a mismatch usually announces itself. ## What it looks like in production Take a nightly job that syncs an inventory between two systems and is deployed to two fleets: a modern base image and an older one kept for a legacy integration. Both pin the same requirements file. On the modern fleet the deploy is a download; on the older one the same install starts compiling, and the deploy step blows the 92nd-percentile time budget the team measures it against, then fails on a machine without a compiler. Nothing changed in the application: the dependency simply raised its manylinux baseline in a patch release, and only one fleet's glibc still satisfies it. The diagnosis takes one comparison — the tags the interpreter on the failing host accepts, against the files the project publishes — and the fixes are all structural: 1. Move the old fleet to a newer base image, so the baseline is satisfied. 2. Pin the dependency to the last version that published a wheel for the older baseline, and treat that as debt with an expiry date. 3. Build the wheel yourself against the older baseline once, host it internally, and install that artefact everywhere. 4. Install with `--only-binary=:all:` regardless, so the mismatch fails in seconds with a clear message rather than silently becoming a compile. ## Why not just compile Because a compile on the target host reintroduces everything the tag exists to avoid: a toolchain in the runtime image, non-reproducible builds, minutes added to every deploy, and a class of failure that only appears on the machines you least want to debug. The baseline is a contract precisely so that installation stays a file copy, and the senior move is to keep it a file copy by controlling the base image and the interpreter version rather than by keeping a compiler around.