79244d366c feet: general approach to auditing wheels with abi3audit default (#2805)
* WIP - initial punt at audit command

* Add `abi3audit` as a dependency

* Add helper functions to check stable ABI wheels

* Run `abi3audit` for macOS and Windows wheels

* Copy out of container for repairing?

* Add some notes that `cibuildwheel` runs `abi3audit`

* Add basic unit tests

* Add a basic C extension with `Py_LIMITED_API`

* Add a test project that violates Stable ABI

* Fix linux test

* Skip abi3 wheel tests for Pyodide

* Patch the correct subprocess module

* wrap cleanup of abi3audit dir

* Write the docs for the new options

* Move to above testing in docs

* Implement audit-requires and audit-command

* Some cleanups after self-review

* Add default value

* fix type errors

* the key is `audit-command`, not `audit`

* Add a variety of tests for audit requires options

* Add `test_audit_requires` similar to `test_test_requires`

* Add some configurability-related audit tests

* Fix parsing error with options docs leaving out commands

* Better way to extract version (maybe helps Pyodide?)

* Fix a case of unbound `use_uv`

* Standardise: rename to `abi3_wheel`

* Fix audit command run message

* Simplify custom audit command a bit

* Remove unnecessary skip for Pyodide

* Pyodide should have no default audit command

* More accurate skip messages for Pyodide skips

* Wheels are audited after they are repaired

* Regenerate constraints to include `abi3audit`

* Fix typos

* Some attempts for Windows fixes

* Check `pyvenv.cfg` instead of directory existence

* Add validation for lack of wheel placeholders

* Try yet another Windows `uv` fix

* Regenerate diagram and re-trigger Azure CI

* Add missing `import sys` for abi3 C extension tests

* Remove audit-command at the global level

* Clarify `abi3audit` pinning a little bit

* Regen constraints

* Discard changes to cibuildwheel/resources/constraints-pyodide312.txt

* Discard changes to cibuildwheel/resources/constraints-pyodide313.txt

* try opt-in uv again

* fix issue on windows on Python 3.13 related to nested venvs

On win / python 3.13, virtualenv creates a venv where the 'home'
points back to the venv that sys.executable was running in, rather
than the root install. that seemingly leads to problems with package
resolution, where pip.exe couldn't find the pip python package.
this appears to fix it!

* Update constraints

* chore: revert python-discovery bump

Assisted-by: OpenCode:glm-5.1
Signed-off-by: Henry Schreiner <henryfs@princeton.edu>

* fix: restore workaround for graalpy

Assisted-by: OpenCode:glm-5.1
Signed-off-by: Henry Schreiner <henryfs@princeton.edu>

---------

Signed-off-by: Henry Schreiner <henryfs@princeton.edu>
Co-authored-by: Agriya Khetarpal <74401230+agriyakhetarpal@users.noreply.github.com>
Co-authored-by: Henry Schreiner <henryfs@princeton.edu>
2026-05-14 07:41:14 -07:00
2026-05-10 21:19:36 -04:00
2023-09-13 16:09:56 -04:00
2026-04-03 20:06:12 -05:00

cibuildwheel

PyPI Documentation Status Actions Status CircleCI Status Azure Status

Documentation

Python wheels are great. Building them across Mac, Linux, Windows, on multiple versions of Python, is not.

cibuildwheel is here to help. cibuildwheel runs on your CI server - currently it supports GitHub Actions, Azure Pipelines, CircleCI, and GitLab CI - and it builds and tests your wheels across all of your platforms.

What does it do?

While cibuildwheel itself requires a recent Python version to run (we support the last three releases), it can target the following versions to build wheels:

macOS Intel macOS Apple Silicon Windows 64bit Windows 32bit Windows Arm64 manylinux
musllinux x86_64
manylinux
musllinux i686
manylinux
musllinux aarch64
manylinux
musllinux ppc64le
manylinux
musllinux s390x
manylinux
musllinux armv7l
Android iOS Pyodide
CPython 3.9 2 4 N/A N/A N/A
CPython 3.10 2 4 N/A N/A N/A
CPython 3.11 2 4 N/A N/A N/A
CPython 3.12 2 4 N/A N/A 3
CPython 3.13 2 4 3
CPython 3.14 2 4 N/A
CPython 3.155 2 4 N/A N/A N/A
PyPy 3.9 v7.3 N/A N/A 1 1 1 N/A N/A N/A N/A N/A N/A
PyPy 3.10 v7.3 N/A N/A 1 1 1 N/A N/A N/A N/A N/A N/A
PyPy 3.11 v7.3 N/A N/A 1 1 1 N/A N/A N/A N/A N/A N/A
GraalPy 3.11 v24.2 N/A N/A 1 N/A 1 N/A N/A N/A N/A N/A N/A
GraalPy 3.12 v25.0 N/A N/A 1 N/A 1 N/A N/A N/A N/A N/A N/A

1 PyPy & GraalPy are only supported for manylinux wheels.
2 Windows arm64 support is experimental.
3 Experimental, not yet supported on PyPI, but can be used directly in web deployment. Use --platform pyodide to build.
4 manylinux armv7l support is experimental. As there are no RHEL based image for this architecture, it's using an Ubuntu based image instead.
5 Python 3.15 requires opt-in using enable.

  • Builds manylinux, musllinux, macOS, and Windows wheels for CPython, PyPy, and GraalPy
  • Works on GitHub Actions, Azure Pipelines, CircleCI, and GitLab CI
  • Bundles shared library dependencies on Linux and macOS through auditwheel and delocate
  • Runs your library's tests against the wheel-installed version of your library

See the cibuildwheel 1 documentation if you need to build unsupported versions of Python, such as Python 2.

Usage

cibuildwheel runs inside a CI service. Supported platforms depend on which service you're using:

Linux macOS Windows Linux ARM macOS ARM Windows ARM Android iOS Pyodide
GitHub Actions 2 4 3
Azure Pipelines 2 4 3 5
CircleCI 45 35 5
GitLab CI 1 45 35 5

1 Requires emulation, distributed separately. Other services may also support Linux ARM through emulation or third-party build hosts, but these are not tested in our CI.
2 Uses cross-compilation. It is not possible to test arm64 on this CI platform.
3 Requires a macOS runner; runs tests on the simulator for the runner's architecture.
4 Building for Android requires the runner to be Linux x86_64, macOS ARM64 or macOS x86_64. Testing has additional requirements.
5 Builds may work, but are untested in cibuildwheel's CI.

Example setup

To build manylinux, musllinux, macOS, and Windows wheels on GitHub Actions, you could use this .github/workflows/wheels.yml:

name: Build

on: [push, pull_request]

jobs:
  build_wheels:
    name: Build wheels on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, ubuntu-24.04-arm, windows-latest, windows-11-arm, macos-15-intel, macos-latest]

    steps:
      - uses: actions/checkout@v6
        with:
          persist-credentials: false

      # Used to host cibuildwheel
      - uses: actions/setup-python@v6

      - name: Install cibuildwheel
        run: python -m pip install cibuildwheel==3.4.1

      - name: Build wheels
        run: python -m cibuildwheel --output-dir wheelhouse
        # to supply options, put them in 'env', like:
        # env:
        #   CIBW_SOME_OPTION: value
        #   ...

      - uses: actions/upload-artifact@v6
        with:
          name: cibw-wheels-${{ matrix.os }}-${{ strategy.job-index }}
          path: ./wheelhouse/*.whl

For more information, including PyPI deployment, and the use of other CI services or the dedicated GitHub Action, check out the documentation and the examples.

How it works

The following diagram summarises the steps that cibuildwheel takes on each platform.

Explore an interactive version of this diagram in the docs.

Warning

Building and testing wheels executes arbitrary code from your project and its dependencies. Although cibuildwheel uses OCI containers and Pyodide for some builds, these provide no security guarantees - the code you're building and testing has full access to the environment that's invoking cibuildwheel.

If you cannot trust all the code that's pulled in, maintain good security hygiene: keep the job that builds distributions separate from the job that uploads them to PyPI, handle secrets and credentials with care and rotate them regularly, and follow the principle of least privilege when granting permissions. Do not store sensitive data on CI runners.

Option Description
Build selection platform Override the auto-detected target platform
build
skip
Choose the Python versions to build
archs Change the architectures built on your machine by default.
project-requires-python Manually set the Python compatibility of your project
enable Enable building with extra categories of selectors present.
allow-empty Suppress the error code if no wheels match the specified build identifiers
Build customization build-frontend Set the tool to use to build, either "build" (default), "build[uv]", or "pip"
config-settings Specify config-settings for the build backend.
environment Set environment variables
environment-pass Set environment variables on the host to pass-through to the container.
before-all Execute a shell command on the build system before any wheels are built.
before-build Execute a shell command preparing each wheel's build
xbuild-tools Binaries on the path that should be included in an isolated cross-build environment.
repair-wheel-command Execute a shell command to repair each built wheel
manylinux-*-image
musllinux-*-image
Specify manylinux / musllinux container images
container-engine Specify the container engine to use when building Linux wheels
dependency-versions Control the versions of the tools cibuildwheel uses
pyodide-version Specify the Pyodide version to use for pyodide platform builds
Auditing audit-requires Install Python dependencies for the audit step
audit-command Use a tool to check wheels before the end of the run
Testing test-command The command to test each built wheel
before-test Execute a shell command before testing each wheel
test-sources Paths that are copied into the working directory of the tests
test-requires Install Python dependencies before running the tests
test-extras Install your wheel for testing using extras_require
test-groups Specify test dependencies from your project's dependency-groups
test-skip Skip running tests on some builds
test-environment Set environment variables for the test environment
test-runtime Controls how the tests will be executed.
Debugging debug-keep-container Keep the container after running for debugging.
debug-traceback Print full traceback when errors occur.
build-verbosity Increase/decrease the output of the build

These options can be specified in a pyproject.toml file, or as environment variables, see configuration docs.

Working examples

Here are some repos that use cibuildwheel.

Name CI OS Notes
scikit-learn github icon windows icon apple icon linux icon pyodide icon The machine learning library. A complex but clean config using many of cibuildwheel's features to build a large project with Cython and C++ extensions.
duckdb github icon apple icon linux icon windows icon DuckDB is an analytical in-process SQL database management system
pytorch-fairseq github icon apple icon linux icon Facebook AI Research Sequence-to-Sequence Toolkit written in Python.
NumPy github icon travisci icon windows icon apple icon linux icon pyodide icon The fundamental package for scientific computing with Python.
NCNN github icon windows icon apple icon linux icon ncnn is a high-performance neural network inference framework optimized for the mobile platform
Matplotlib github icon windows icon apple icon linux icon pyodide icon The venerable Matplotlib, a Python library with C++ portions
Tornado github icon linux icon apple icon windows icon Tornado is a Python web framework and asynchronous networking library. Uses stable ABI for a small C extension.
MyPy github icon apple icon linux icon windows icon The compiled version of MyPy using MyPyC.
Prophet github icon windows icon apple icon linux icon Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.
Triton github icon linux icon Self hosted runners

That's just a handful, there are many more! Check out the Working Examples page in the docs.

Since cibuildwheel repairs the wheel with delocate or auditwheel, it might automatically bundle dynamically linked libraries from the build machine.

It helps ensure that the library can run without any dependencies outside of the pip toolchain.

This is similar to static linking, so it might have some license implications. Check the license for any code you're pulling in to make sure that's allowed.

Changelog

v3.4.1

2 April 2026

  • ⚠️ Building for the experimental CPython 3.13 free-threading variant is now deprecated. That functionality will be removed in the next minor release. The enable option cpython-freethreading is therefore also deprecated. Builds specifying enable = "all" no longer select cpython-freethreading. CPython 3.14 free-threading support remains available without the enable flag. (#2787)
  • 🐛 iOS builds will no longer skip repair-wheel-command if it's defined in config (#2761)
  • 🐛 Fix bug causing uv to fail when environments define PYTHON_VERSION or UV_PYTHON, conflicting with our venvs (#2795)
  • cibuildwheel prints the selected build identifiers at the start of the build. (#2785)
  • 🔐 The GitHub Action now references other actions with a full SHA (#2744)

v3.4.0

5 March 2026

  • 🌟 You can now build wheels using uv as a build frontend. This should improve performance, especially if your project has lots of build dependencies. To use, set build-frontend to uv. (#2322)
  • ⚠️ We no longer support running on Travis CI. It may continue working but we don't run tests there anymore so we can't be sure. (#2682)
  • Improvements to building rust wheels on Android (#2650)
  • 🛠 Update Pyodide to 0.29.3 (#2719, #2733)
  • 🐛 Fix bug with the GitHub Action on Windows, where PATH was getting unnecessarily changed, causing issues with meson builds. (#2723)
  • Add support for quiet setting on build and uv from the cibuildwheel build-verbosity setting. (#2737)
  • 📚 Docs updates, including guidance on using Meson on Windows (#2718)

v3.3.1

5 January 2026

  • 🛠 Update dependencies and container pins, including updating to CPython 3.14.2. (#2708)

v3.3.0

12 November 2025

  • 🐛 Fix an incompatibility with Docker v29 (#2660)
  • Adds test-runtime option, to customise how tests on simulated/emulated environments are run (#2636)
  • Adds support for new manylinux_2_35 images on 32-bit ARM armv7l, offering better C++20 compatibility (#2656)
  • build[uv] is now supported on Android (#2587)
  • You can now install extras (such as uv) with a simple option on the GitHub Action (#2630)
  • {project} and {package} placeholders are now supported in repair-wheel-command (#2589)
  • 🛠 The versions set with dependency-versions no longer constrain packages specified by your build-system.requires. Previously, on platforms other than Linux, the constraints in this option would remain in the environment during the build. This has been tidied up make behaviour more consistent between platforms, and to prevent version conflicts. (#2583)
  • 🛠 Improve the handling of test-command on Android, enabling more options to be passed (#2590)
  • 📚 Docs improvements (#2618)

v3.2.1

12 October 2025

  • 🛠 Update to CPython 3.14.0 final (#2614)
  • 🐛 Fix the default MACOSX_DEPLOYMENT_TARGET on Python 3.14 (#2613)
  • 📚 Docs improvements (#2617)

That's the last few versions.

Want more changelog? Head over to the changelog page in the docs.


Contributing

For more info on how to contribute to cibuildwheel, see the docs.

Everyone interacting with the cibuildwheel project via codebase, issue tracker, chat rooms, or otherwise is expected to follow the PSF Code of Conduct.

Maintainers

Core:

Platform maintainers:

Credits

cibuildwheel stands on the shoulders of giants.

Massive props also to-

  • @zfrenchee for help debugging many issues
  • @lelit for some great bug reports and contributions
  • @mayeut for a phenomenal PR patching Python itself for better compatibility!
  • @czaki for being a super-contributor over many PRs and helping out with countless issues!
  • @mattip for his help with adding PyPy support to cibuildwheel

See also

Another very similar tool to consider is matthew-brett/multibuild. multibuild is a shell script toolbox for building a wheel on various platforms. It is used as a basis to build some of the big data science tools, like SciPy.

If you are building Rust wheels, you can get by without some of the tricks required to make GLIBC work via manylinux; this is especially relevant for cross-compiling, which is easy with Rust. See maturin-action for a tool that is optimized for building Rust wheels and cross-compiling.

S
Description
No description provided
Readme BSD-2-Clause
9.7 MiB
Languages
Python 100%