Build1 publisher3 min readPublished
Apple's coreai-models 0.1.0 wheel locks out the Python 3.11 its repo declares
Apple's coreai-models 0.1.0 wheel on PyPI requires Python 3.14, though its own pyproject.toml declares 3.11 and up. PyPI files cannot be edited, so the issue's closure on 16 July left the published wheel and sdist refusing every Python below 3.14.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- On Python 3.11.15 the resolver refuses the install outright, reporting that coreai-models 0.1.0 depends on Python>=3.14.
- Besides pyproject.toml, the repository's .python-version file also pins 3.11, as noted in issue #96.
- A new zero-dependency CLI, wheelreach, flags the coreai-models wheel as blocked by metadata on 3.11 and 3.12 and eligible only on 3.14.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A pin of coreai-models==0.1.0 on Python 3.11 through 3.13 will fail for as long as that version exists, so a working pin needs a successor release.
- decision A check that validates pyproject.toml would have passed this release, so a check that catches it has to run against the uploaded wheel's METADATA.
- exposure Triton nightly users who move to Python 3.15 hit the same failure from the other side, fetching a tag-matched wheel that pip then rejects.
- constraint A clean wheelreach v0.1.0 run covers only CPython on Linux x86-64, leaving compiled macOS, Windows and ARM wheels unchecked.
The wheelreach output in the dev.to post that reported the problem names the file on PyPI: `coreai_models-0.1.0-py3-none-any.whl` [12]. Its tags py3, none and any mean any Python 3, no compiled ABI and any platform [5]. Run against 3.11 and 3.12, wheelreach finds that same file and marks both `BLOCKED_BY_REQUIRES_PYTHON` [12]. The tool defines that verdict as a wheel that exists for that Python while the metadata excludes it [13]. The only thing keeping 3.11 out is the `Requires-Python: >=3.14` line inside the wheel [2][1].
The resolver works from the artifact. Its error on 3.11.15 cites `>=3.14`, the artifact's value, and the `>=3.11` in `python/pyproject.toml` plays no part [3][4][2]. The post's author, who built wheelreach, has a theory for the drift. "Somebody bumped a build setting and never noticed, because nothing checks that the thing you publish agrees with the thing you declare," the author wrote [6].
"Closing the ticket didn't fix what's already published," the author wrote [8]. The issue tracker and the package index do not share state. With the 0.1.0 files immutable, users on 3.11, 3.12 and 3.13 can only get a working install from a new upload [7][3].
Triton's nightly wheels show the mismatch running the other way, according to pytorch/pytorch#186099 [9]. They are built with cp315 tags, but their METADATA says `Requires-Python: >=3.10,<3.15` [9]. The author describes pip downloading a wheel built for the user's exact Python and then refusing to install it [10]. On 3.15 that wheel gets the same wheelreach verdict as Apple's: the tag matches and the metadata excludes it [4].
A `Requires-Python` exclusion is a bug only relative to what the project promised, so the tool asks for the promise. I think this is the right design. `--expected-python` takes the range a project intends to support, here copied from the repo's own pyproject.toml [14]. With it, the 3.10 exclusion becomes `OUT_OF_SCOPE`, because the project never promised 3.10 [12][14]. Without it, a blocked wheel is reported only as "excluded by metadata" [14].
Two other verdicts are set sensibly. `NO_WHEEL_HAS_SDIST` is informational, since pip can build an sdist, and `UNKNOWN_METADATA` counts as a problem, never a silent pass [15]. Exit codes are 1 on problems, 0 when clean and 2 on errors, for use as a post-release CI job [16]. The tool is a zero-dependency CLI and the fifth in the author's release-integrity series [11].
The check is syntactic. It evaluates wheel filename tags and `Requires-Python` without a trial install, so a pass means pip should accept the file. It does not mean the code runs [18]. Version 0.1.0 models CPython on Linux x86-64 only, the shape both cases above hit, and leaves macOS, Windows, ARM and PyPy out [17]. For coreai-models that limit costs nothing, because a none-any wheel is not tied to a platform [5].
What to watch
- Whether Apple yanks coreai-models 0.1.0 or ships a successor whose METADATA matches the >=3.11 in pyproject.toml.
- Whether the Triton nightlies in pytorch/pytorch#186099 widen Requires-Python to admit 3.15 or drop the cp315 builds.
- Whether wheelreach extends beyond its syntactic Linux x86-64 CPython check to macOS, ARM, PyPy or trial installs.