Ship one py3-none wheel per platform instead of per-Python-version#22
Merged
Conversation
libvcell is pure Python plus a ctypes-loaded GraalVM native library, with no compiled CPython extension. The wheel therefore has no CPython ABI dependency and does not need to be built/tagged per Python version (cp310..cp314). Build a single interpreter (cp311) per platform with cibuildwheel (keeping its auditwheel/delocate/delvewheel repair so the manylinux/macosx/win platform tags stay correct), then retag the result cp311-cp311-<platform> -> py3-none-<platform>. Requires-Python in the wheel metadata still enforces the >=3.10 floor. Effect: ~5x fewer wheels and ~5x less storage per release (~34 -> ~7 wheels, ~1.45GB -> ~0.28GB), and a correspondingly faster release build. This addresses the PyPI 10GB project-size limit that the per-cp matrix was driving toward. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
libvcellis pure Python + a ctypes-loaded GraalVM native library — there is no compiled CPython extension (native_utils.pyusesctypes.CDLL;build.pyhas noExtension/ext_modules). So the wheel has no CPython ABI dependency and does not need to be built or tagged per Python version.What
cp311) per platform with cibuildwheel (keeping auditwheel/delocate/delvewheel repair, somanylinux/macosx/winplatform tags stay valid).cp311-cp311-<platform>→py3-none-<platform>(python -m wheel tags --python-tag py3 --abi-tag none --remove), preserving the platform tag.Effect
This is the structural fix for the PyPI 10 GB project-size limit the per-cp matrix was driving the project toward, and it roughly 5× speeds up the release build.
Validation
The retag mechanism is the same one used to produce the local macOS arm wheels in this effort (verified: the identical dylib loads on Python 3.12 and 3.14). The release workflow isn't exercised by PR CI, so before relying on it you can manually run the workflow (
workflow_dispatch) — the publish step is gated onreleaseevents, so a dispatch run builds + dry-run-publishes the py3-none wheels without uploading.Follow-up (not in this PR)
The
glibc: [2_28, 2_34]matrix now yields two redundant Linux wheels per arch — amanylinux_2_28wheel already installs on glibc ≥2.28 (incl. 2.34). Dropping the2_34dimension is a safe further reduction.🤖 Generated with Claude Code