Apple 的 coreai-models 0.1.0 声称支持 Python 3.11，wheel 却要求 3.14

Apple's coreai-models 0.1.0 is on PyPI right now. Try installing it on Python 3.11:

Because the current Python version (3.11.15) does not satisfy Python>=3.14
and coreai-models==0.1.0 depends on Python>=3.14, we can conclude that
coreai-models==0.1.0 cannot be used.

The wheel's metadata says Requires-Python: >=3.14. But the repo's own python/pyproject.toml says requires-python = ">=3.11", and .python-version pins 3.11 (issue #96). The source claims 3.11; the published artifact forbids it. Somebody bumped a build setting and never noticed, because nothing checks that the thing you publish agrees with the thing you declare.

One wrinkle worth stating precisely: the upstream issue was closed on 2026-07-16, but PyPI artifacts are immutable — the published 0.1.0 wheel and sdist still declare >=3.14 today. Closing the ticket didn't fix what's already published. Run the check below right now and it still flags it.

And it's not just Apple. pytorch/pytorch#186099: triton nightly wheels are compiled with cp315 tags, but their METADATA still says Requires-Python: >=3.10,<3.15 — pip downloads a wheel built for your exact Python and then refuses to install it.

The missing check

This is the fifth tool in my release-integrity series — the question each one asks is "the release passed, but what actually shipped?"

readmeta: did your README render on PyPI, or are the images broken?
wheeltruth: did your wheel ship complete, or are files missing?
casecrash: will your filenames survive checkout on another OS?
tagtruth: do your PyPI versions actually have matching Git tags?
wheelreach: can your Python actually install what you declared it supports?

wheelreach is a zero-dependency Python CLI. Point it at a package:

pip install wheelreach
wheelreach check --package coreai-models --expected-python ">=3.11"

version  python  verdict                     wheel
-------  ------  --------------------------  ------------------------------------
0.1.0    3.10    OUT_OF_SCOPE                -
0.1.0    3.11    BLOCKED_BY_REQUIRES_PYTHON  coreai_models-0.1.0-py3-none-any.whl
0.1.0    3.12    BLOCKED_BY_REQUIRES_PYTHON  coreai_models-0.1.0-py3-none-any.whl
0.1.0    3.14    WHEEL_ELIGIBLE              coreai_models-0.1.0-py3-none-any.whl

checked 5 version/python pairs, 3 problem(s)

--expected-python is the honest scoping mechanism: it declares which Pythons the project intends to support (here, from the repo's own pyproject.toml). A 3.10 exclusion isn't a bug when the project only promises 3.11+ — so it's OUT_OF_SCOPE, not a problem. Without the flag, a blocked wheel is reported as "excluded by metadata"; with it, you get a bug-or-not verdict.

Exit code 1 on problems, 0 when clean, 2 on errors — a post-release CI job.

Six verdicts, not two

The interesting design decision: "no wheel" is not one thing, and "blocked" needs a scope.

WHEEL_ELIGIBLE — a compatible wheel exists and metadata allows this Python. (Named carefully: eligibility, not a promise the code runs.)
BLOCKED_BY_REQUIRES_PYTHON — a wheel exists for this Python but the metadata excludes it. The Apple failure mode.
NO_WHEEL — no compatible wheel and no sdist. Nothing installable at all.
NO_WHEEL_HAS_SDIST — no compatible wheel, but an sdist exists that might build. Informational only — pip can build it, so it doesn't fail the check.
UNKNOWN_METADATA — the Requires-Python couldn't be parsed, so the check was impossible. A problem, never a silent pass.
OUT_OF_SCOPE — outside --expected-python. Not checked, not a problem.

What wheelreach does not verify

The target model is CPython on Linux x86-64 — the most common CI/server shape, and the one both real cases above hit. macOS, Windows, ARM, and PyPy are out of scope for v0.1.0. Compatibility is syntactic (wheel filename tags + Requires-Python evaluation), not a trial install in a fresh interpreter: a passing check means pip should accept the file, not a guarantee the code runs.

The release passed. Now check what actually shipped: github.com/hahahahahahahahah6/wheelreach