coremltools: Add version 9.0 - #2106
Merged
Merged
Conversation
Build the libmilstoragepython/libmodelpackage pybind11 extensions and the wheel the way upstream's scripts/build.sh does (CMake, then the `dist` target), narrowed to the manylinux_2_39_riscv64 container.
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
381: a `cpXY-none-<platform>` wheel whose setup.py declares no ext_modules at all, with the extension modules and the platform tag both supplied by a sibling CMake build. 382: a CMake build that shells out to a bare `python3` for one vendored sub-extension builds it for the container's default interpreter instead of the one the wheel is for.
luhenry
changed the title
Restores skills/python-project-porting/references/{gotchas-index.md,
gotchas/cibuildwheel-matrix-and-abi3.md, gotchas/native-build-bazel-and-drivers.md}
to main's current content. The two gotchas this PR had added (381/382, the
cpXY-none plat-name shape and the CMake-shells-out-to-bare-python3 case)
also collided with gotcha numbers other agents had already taken on main
in the meantime - they'll be re-added on main directly with fresh numbers.
…is branch no longer touches
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
These were originally added inside PR #2106 (coremltools), which is not allowed to touch skills/ - removed from that branch and landed here instead, renumbered from their original 381/382 (already taken by other concurrent work by the time this was caught).
Contributor
|
Both riscv64 jobs failed ~30s in with
error: can't open patch '../python-wheels/patches/coremltools/9.0/00*.patch': No such file or directory
`git -C coremltools apply ../python-wheels/...` changes the directory for
git only - the shell still expands the glob relative to the step's own cwd,
which is the workspace root. The repo name doubles in the runner's workspace
path (/home/runner/work/python-wheels/python-wheels), so `../python-wheels`
from there resolves back to the workspace itself, the glob matches nothing
and bash hands git the literal `00*.patch`.
Use `working-directory: coremltools` with a plain `git apply` so the shell
and git share one base, matching what every other subdirectory-checkout
workflow here does (build-ray.yml, build-tink.yml, build-torch.yml, ...).
Also list patches/coremltools/** in the triggers so a patch-only change
rebuilds.
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
…al glob Both riscv64 jobs of the coremltools port (#2106) died 30s in with `can't open patch '.../00*.patch': No such file or directory` while the patch file was plainly committed on the branch. The shell expands the glob in the step's own cwd - $GITHUB_WORKSPACE - and `git -C` moves only git, so git got the six literal characters `00*.patch`. The runner workspace doubles this repo's name (work/python-wheels/python-wheels), so `../python-wheels` from the workspace root resolves back onto the workspace and the glob fails silently rather than erroring on a missing directory. Records the fix (`working-directory:` + plain `git apply`, as build-ray.yml and friends already do), the note that an x86_64 rehearsal cannot exercise runner-layout wiring at all, and the reminder to list patches/<pkg>/** in the triggers.
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
…d and re-running Record the root cause of PR #2106's two failing riscv64 legs (the `git -C` + glob base mismatch, gotcha 413), the fix pushed to the branch, and what local QEMU validation did and did not cover.
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.
coremltools9.0Compiles the
libmilstoragepythonandlibmodelpackagepybind11 extensions against the vendored protobuf 3.19, nlohmann-json and FP16 trees. Upstream publishes no riscv64 wheel.Mirrors upstream's
scripts/build.sh(CMake, then thedisttarget), narrowed to the manylinux_2_39_riscv64 container.Differs from upstream
/opt/python/cpXYinterpreter is used directly.auditwheel repairreplaces upstream's hand-setmanylinux1tag.libuuid-devel, whichmodelpackagelinks against.Matrix: cp312/cp313 only — upstream supports up to 3.13 and the vendored pybind11 2.13.1 predates 3.14.
Testing
coremltools.testandmiljobs that collects without torch, tensorflow, scikit-learn or xgboost, none of which have riscv64 wheels.import torchinside the test body.License: Wheel bundles protobuf, pybind11, nlohmann-json, FP16 (all BSD-3-Clause/MIT) and libuuid; upstream ships licence text only for kmeans1d, so the build adds the rest.
Patches
0001-cmake-derive-the-Linux-wheel-platform-tag-from-the-ta.patch- To upstream. Without it every Linux wheel is taggedmanylinux1_x86_64; reproduces on any non-x86_64 Linux.Built and tested on cp312 on x86_64 as a rehearsal; 226 passed, 117 skipped.