You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Versions 3.16/3.17 macOS wheels missing for CPython 3.14 (non-free-threaded) #317
Version 3.15 shipped macOS wheels for CPython 3.14, however, versions 3.16 and 3.17 do not. On macOS, 3.14 is now covered only by the free-threaded build (cp314t). Installing on macOS + CPython 3.14 with the GIL therefore falls back to the sdist and needs a Rust toolchain.
$ pip install --only-binary=:all: grimp==3.17
ERROR: Could not find a version that satisfies the requirement grimp==3.17
Comparing wheel tags on PyPI (3.17's tag coverage is identical to 3.16's):
Lost in 3.16, present in 3.15:
grimp-3.15-cp314-cp314-macosx_11_0_arm64.whl
grimp-3.15-cp314-cp314-macosx_10_12_x86_64.whl
Gained in 3.16 (abridged): cp314-cp314t-macosx_11_0_arm64, cp314-cp314t-macosx_10_12_x86_64, cp315-cp315t-macosx_*, and various win_arm64 / cp314t / cp315 Windows wheels.
macOS coverage per release:
Release
macOS wheels
3.15
cp310–cp314 (x86_64 + arm64)
3.16, 3.17
cp310–cp313 (x86_64 + arm64), plus cp314t and cp315t (no cp314, no cp315)
Linux and Windows are unaffected: cp314-cp314-manylinux_2_17_aarch64, …_x86_64, cp314-cp314-win_amd64 etc. are all present in 3.16/3.17.
v3.16/v3.17: only grimp-3.16-cp314-cp314t-macosx_*.whl — the plain cp314 wheel is gone entirely
Root cause: commit 53f7e7e ("Add support for Python 3.14t") added 3.14t alongside 3.14 in the same actions/setup-python step for the macos job in .github/workflows/release.yml, still relying on maturin build --find-interpreter to auto-discover both. find-interpreter probes for a binary literally named python3.14 on PATH. Because both the regular and free-threaded macOS Python installs register a bin/python3.14 (the free-threaded build isn't given a t-suffixed binary name on macOS the way CPython's own build system does), and actions/setup-python's core.addPath prepends each install's bin dir in the order given, the free-threaded 3.14t install (listed after 3.14) ends up shadowing the standard one on PATH. --find-interpreter then only ever finds the free-threaded interpreter under the name python3.14, so it builds (and correctly tags) a cp314-cp314t wheel — but the standard cp314-cp314 wheel is never built at all.
Supporting evidence: this is exactly the class of problem already fixed for Windows in commit ec5eca2 ("Separate Windows build for free-threaded Python"), which followed maturin-action's own README guidance to build regular and free-threaded interpreters in separate setup-python/maturin build steps to avoid interpreter collisions. That fix was applied to windows only — macos (and linux, though Linux builds happen inside manylinux containers with fixed per-ABI interpreter paths, so it isn't affected) still uses the single-step --find-interpreter approach and has the same latent bug Windows had.
Fix: apply the same separate-steps pattern to the macos job — one setup-python + maturin build --interpreter pass for 3.10 3.11 3.12 3.13 3.14 3.15, and a second pass for 3.14t 3.15t.
We are indeed using Grimp 3.17, but both 3.16 and 3.17 are missing macos and Linux aarch64 wheels (actually only the 3.15 freethreaded has macos wheels).
Activity
seddonym commentedon Sep 10, 2026
Thanks so much for raising - this wasn't intentional. I'll look into it.
seddonym commentedon Sep 11, 2026
Analysis from Claude Code:
The bug: macOS wheels for standard (non-free-threaded) CPython 3.14 disappeared starting in v3.16, replaced by only the free-threaded variant.
Confirmed via PyPI wheel listings:
Root cause: commit 53f7e7e ("Add support for Python 3.14t") added 3.14t alongside 3.14 in the same actions/setup-python step for the macos job in .github/workflows/release.yml, still relying on maturin build --find-interpreter to auto-discover both. find-interpreter probes for a binary literally named python3.14 on PATH. Because both the regular and free-threaded macOS Python installs register a bin/python3.14 (the free-threaded build isn't given a t-suffixed binary name on macOS the way CPython's own build system does), and actions/setup-python's core.addPath prepends each install's bin dir in the order given, the free-threaded 3.14t install (listed after 3.14) ends up shadowing the standard one on PATH. --find-interpreter then only ever finds the free-threaded interpreter under the name python3.14, so it builds (and correctly tags) a cp314-cp314t wheel — but the standard cp314-cp314 wheel is never built at all.
Supporting evidence: this is exactly the class of problem already fixed for Windows in commit ec5eca2 ("Separate Windows build for free-threaded Python"), which followed maturin-action's own README guidance to build regular and free-threaded interpreters in separate setup-python/maturin build steps to avoid interpreter collisions. That fix was applied to windows only — macos (and linux, though Linux builds happen inside manylinux containers with fixed per-ABI interpreter paths, so it isn't affected) still uses the single-step --find-interpreter approach and has the same latent bug Windows had.
Fix: apply the same separate-steps pattern to the macos job — one setup-python + maturin build --interpreter pass for 3.10 3.11 3.12 3.13 3.14 3.15, and a second pass for 3.14t 3.15t.
seddonym commentedon Sep 11, 2026
This should now be fixed. I've also uploaded the missing wheels for those two versions.
Thanks for raising @jamesbeith !
jamesbeith commentedon Sep 15, 2026
Working for me now, thanks!
Viicos commentedon Oct 13, 2026
Thanks for the fix, would it be possible to have 3.15 wheels also uploaded?
seddonym commentedon Oct 13, 2026
Grimp comes with CPython 3.15 wheels from Grimp version 3.16+. Any reason you can't use a recent version of Grimp?
Viicos commentedon Oct 13, 2026
We are indeed using Grimp 3.17, but both 3.16 and 3.17 are missing macos and Linux aarch64 wheels (actually only the 3.15 freethreaded has macos wheels).
seddonym commentedon Oct 15, 2026
Ok, I've created a separate issue here.