CI: build wheels natively per arch (fix duplicate/colliding wheels; add win_arm64) - #317
Merged
Conversation
…add win_arm64 The build matrix had a cross `arch: [x86_64, arm64]` dimension, but only CIBW_ARCHS_MACOS was wired to it. On the x86 ubuntu-24.04 / windows-latest runners the `arch: arm64` leg therefore ignored the arch and rebuilt the native x86_64 / amd64 wheel, just under an artifact named "...-arm64-...". That caused: - duplicate manylinux-x86_64 and win_amd64 wheels (10 of them), which collided during the release job's `download-artifact --merge-multiple` and intermittently produced a truncated wheel -> `twine check` BadZipFile -> failed PyPI publish; - no real win_arm64 wheels ever being built. Replace the broken cross-arch dimension with one runner per native target architecture (cibuildwheel builds the native arch by default), and add a native windows-11-arm leg for real win_arm64 wheels (3.11+ only; marked continue-on-error since embree/predicates use x86 SIMD and may not build yet). Artifact names are now unique per (os, python), so nothing collides on merge. Bump version to 2.6.4.dev0 so merging this exercises the fixed publish pipeline end-to-end (a pre-release upload to PyPI). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The windows-11-arm leg fails building embree: embree only enables its NEON
(sse2neon) code path when its CMake detects an ARM target, and on Windows/MSVC
ARM64 that detection falls back to SSE2 ("Detected default ISA: SSE2"), so it
compiles x86 SSE sources and MSVC's immintrin.h rejects them on ARM64. (macOS
arm64 works because embree's arm/NEON path is detected and supported there.)
Pass CMAKE_ARGS=-DLIBIGL_EMBREE=OFF only on the windows-11-arm leg so win_arm64
wheels build without the igl.embree submodule. Other platforms keep embree.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cibuildwheel runs `pytest {project}/tests` on every wheel, and the win_arm64
wheel is built without embree (no MSVC/ARM64 embree). The unconditional
`import igl.embree` at module scope aborted collection there. Guard the import
(HAS_EMBREE) and skip test_embree / test_new_embree_algorithms when it's absent.
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.
The bug (diagnosed from the 2.6.3 release)
The
build_wheelsmatrix had a crossarch: [x86_64, arm64]dimension, but onlyCIBW_ARCHS_MACOS: ${{ matrix.arch }}was wired to it — there was noCIBW_ARCHS_LINUX/CIBW_ARCHS_WINDOWS. So on the x86ubuntu-24.04andwindows-latestrunners, thearch: arm64leg ignoredmatrix.archand rebuilt the native x86_64 / amd64 wheel, just stored under an artifact named…-arm64-….Confirmed from the 2.6.3 run's artifacts:
wheels-windows-latest-arm64-cp310/→…-cp310-win_amd64.whlwheels-ubuntu-24.04-arm64-cp310/→…-cp310-manylinux…x86_64.whlConsequences:
download-artifact@v4 --merge-multiple, the duplicate filenames collided and intermittently produced a truncated wheel →twine checkBadZipFile→ failed PyPI publish (this is what failed the 2.6.3 release twice; also the 10 ×400 Bad Request"file already exists" on the manual upload).win_arm64wheels were ever built (Windows-on-ARM users get nothing). Linuxaarch64was fine only because of the separate nativeubuntu-24.04-armrunner.The fix
archdimension; use one runner per native target architecture (cibuildwheel builds the runner's native arch by default). Artifact names are now unique per(os, python), so nothing collides on merge.windows-11-armleg for realwin_arm64wheels (CPython 3.11+ only). It's markedcontinue-on-errorbecause embree / predicates use x86 SIMD and may not build on ARM64 yet — so if that leg fails, it won't block the release; CI will tell us whether the toolchain is ready.Net platform coverage vs. what's actually on PyPI today: identical, plus win_arm64 (and 10 fewer redundant build jobs).
Version bump to test the pipeline
Bumps
pyproject.tomlto2.6.4.dev0. Merging this tomainwill exercise the fixed publish pipeline end-to-end:check_versionsees the bump, and (with the collisions gone) the release job should tag2.6.4.dev0, create a pre-release GitHub Release, and upload to PyPI cleanly..dev0is flagged as a pre-release, so it won't become the defaultpip install libigl.🤖 Generated with Claude Code