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— theRequires-Pythoncouldn'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
Top comments (0)