Skip to content

ci: build full cp310-cp313 macOS wheels via cibuildwheel - #35

Merged
ddehilster merged 1 commit into
VisualText:mainfrom
ddehilster:ci/macos-cibuildwheel-cp313
Jul 1, 2026
Merged

ddehilster merged 1 commit into
VisualText:mainfrom
ddehilster:ci/macos-cibuildwheel-cp313

Conversation

@ddehilster

Copy link
Copy Markdown
Member

Problem

Follow-up to #34 (which fixed the missing cp313 wheels on Linux/Windows). The macOS job was still under-building:

- name: Build wheels
  run: pip wheel -C "cmake.args=..." -v .

A bare pip wheel . builds exactly one wheel — for the runner's host Python (currently cp314) — and bundles no ICU dylibs. So macOS users on cp310–cp313 got no wheel and fell through to the source sdist, which can't build without a local ICU/vcpkg toolchain. Recent releases show this: only a lone cp314-macosx_arm64 wheel, nothing for cp310–cp313.

Fix

  • publish.yml: convert the macOS job to pypa/cibuildwheel@v2.23.4 (same as the Linux/Windows jobs). ICU comes from the vcpkg manifest via johnwason/vcpkg-action (mirroring the Windows job), and cibuildwheel's default delocate repair vendors the dylibs into each wheel — something the bare pip wheel never did.
  • pyproject.toml: drop cp*-macosx_arm64 from skip. macOS-latest is an arm64 (Apple Silicon) runner, so with the skip in place cibuildwheel would build nothing. (It was only harmless before because the bare pip wheel bypassed cibuildwheel entirely.)

Result

cibuildwheel --print-build-identifiers --platform macos --arch arm64 against this config:

cp310-macosx_arm64
cp311-macosx_arm64
cp312-macosx_arm64
cp313-macosx_arm64

Full cp310–cp313 coverage, consistent with Linux/Windows. Note this intentionally drops the lone cp314 wheel — cibuildwheel 2.23.4's build set is cp310–cp313, matching the other platforms. The wheels also pick up cibuildwheel's default arm64 deployment target (macosx_11_0), so they install on more Macs than the previous macosx_15+/26 tags.

Validation

publish.yml runs on: pull_request (the upload/release steps are gated on refs/tags/v*), so this PR's CI builds the macOS wheels without publishing. Please check the "Build wheels on MacOS" job on this PR produces cp310–cp313 macosx_arm64 wheels before merging. After merge, a normal release (the Release workflow) will publish them.

Not in scope

Intel macOS (macosx_x86_64) wheels — would need an Intel runner (macos-13) or cross-build; the project has only ever shipped arm64. Can be a separate PR if desired.

🤖 Generated with Claude Code

The macOS job used a bare `pip wheel .`, which built exactly one wheel for
the runner's host Python (currently cp314) and bundled no ICU dylibs. So
macOS users on cp310-cp313 had no wheel and fell through to the
unbuildable sdist -- the same gap just fixed for Windows/Linux cp313.

Switch the job to cibuildwheel@v2.23.4 (matching the other platforms),
installing ICU through the vcpkg manifest with johnwason/vcpkg-action and
letting cibuildwheel default delocate vendor the dylibs. Drop the
cp*-macosx_arm64 skip from pyproject: macOS-latest is an arm64 runner,
so that skip would otherwise leave the job with nothing to build.

Verified the matrix with cibuildwheel --print-build-identifiers
--platform macos --arch arm64: cp310/cp311/cp312/cp313-macosx_arm64.

publish.yml runs on pull_request, so this PR CI builds the macOS wheels
without publishing -- inspect that run before merging/releasing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ddehilster
ddehilster merged commit 81b9523 into VisualText:main Jul 1, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant