🎡 Build Python wheels for all the platforms on CI with minimal configuration.

Python Packaging Authority

Last update: Jan 2, 2023

Related tags

DevOps Tools python circleci travis-ci ci pypi build-automation wheel appveyor python-wheels azure-pipelines github-actions

Overview

cibuildwheel

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, Travis CI, AppVeyor, CircleCI, and GitLab CI - and it builds and tests your wheels across all of your platforms.

What does it do?

	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
CPython 3.6	✅	N/A	✅	✅	N/A	✅	✅	✅	✅	✅
CPython 3.7	✅	N/A	✅	✅	N/A	✅	✅	✅	✅	✅
CPython 3.8	✅	✅	✅	✅	N/A	✅	✅	✅	✅	✅
CPython 3.9	✅	✅	✅	✅	✅ ²	✅ ³	✅	✅	✅	✅
CPython 3.10	✅	✅	✅	✅	✅ ²	✅	✅	✅	✅	✅
PyPy 3.7 v7.3	✅	N/A	✅	N/A	N/A	✅ ¹	✅ ¹	✅ ¹	N/A	N/A
PyPy 3.8 v7.3	✅	N/A	✅	N/A	N/A	✅ ¹	✅ ¹	✅ ¹	N/A	N/A

^{¹ PyPy is only supported for manylinux wheels.}
^{² Windows arm64 support is experimental.}
^{³ Alpine 3.14 and very briefly 3.15's default python3 was not able to load musllinux wheels. This has been fixed; please upgrade the python package if using Alpine from before the fix.}

Builds manylinux, musllinux, macOS 10.9+, and Windows wheels for CPython and PyPy
Works on GitHub Actions, Azure Pipelines, Travis CI, AppVeyor, 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
GitHub Actions	✅	✅	✅	✅ ¹
Azure Pipelines	✅	✅	✅
Travis CI	✅		✅	✅
AppVeyor	✅	✅	✅
CircleCI	✅	✅
Gitlab CI	✅

^{¹ 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.}

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-20.04, windows-2019, macOS-10.15]

    steps:
      - uses: actions/checkout@v2

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

      - name: Install cibuildwheel
        run: python -m pip install cibuildwheel==2.3.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@v2
        with:
          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.

Options

	Option	Description
Build selection	`CIBW_PLATFORM`	Override the auto-detected target platform
	`CIBW_BUILD` `CIBW_SKIP`	Choose the Python versions to build
	`CIBW_ARCHS`	Change the architectures built on your machine by default.
	`CIBW_PROJECT_REQUIRES_PYTHON`	Manually set the Python compatibility of your project
	`CIBW_PRERELEASE_PYTHONS`	Enable building with pre-release versions of Python if available
Build customization	`CIBW_BUILD_FRONTEND`	Set the tool to use to build, either "pip" (default for now) or "build"
	`CIBW_ENVIRONMENT`	Set environment variables needed during the build
	`CIBW_ENVIRONMENT_PASS_LINUX`	Set environment variables on the host to pass-through to the container during the build.
	`CIBW_BEFORE_ALL`	Execute a shell command on the build system before any wheels are built.
	`CIBW_BEFORE_BUILD`	Execute a shell command preparing each wheel's build
	`CIBW_REPAIR_WHEEL_COMMAND`	Execute a shell command to repair each (non-pure Python) built wheel
	`CIBW_MANYLINUX__IMAGE` `CIBW_MUSLLINUX__IMAGE`	Specify alternative manylinux / musllinux Docker images
	`CIBW_DEPENDENCY_VERSIONS`	Specify how cibuildwheel controls the versions of the tools it uses
Testing	`CIBW_TEST_COMMAND`	Execute a shell command to test each built wheel
	`CIBW_BEFORE_TEST`	Execute a shell command before testing each wheel
	`CIBW_TEST_REQUIRES`	Install Python dependencies before running the tests
	`CIBW_TEST_EXTRAS`	Install your wheel for testing using extras_require
	`CIBW_TEST_SKIP`	Skip running tests on some builds
Other	`CIBW_BUILD_VERBOSITY`	Increase/decrease the output of pip wheel

These options can be specified in a pyproject.toml file, as well; see configuration.

Working examples

Here are some repos that use cibuildwheel.

Name	CI	OS	Notes
scikit-learn			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.
Tornado			Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed.
pytorch-fairseq			Facebook AI Research Sequence-to-Sequence Toolkit written in Python.
Matplotlib			The venerable Matplotlib, a Python library with C++ portions
MyPy			MyPyC, the compiled component of MyPy.
pydantic			Data parsing and validation using Python type hints
uvloop			Ultra fast asyncio event loop.
psutil			Cross-platform lib for process and system monitoring in Python
vaex			Out-of-Core hybrid Apache Arrow/NumPy DataFrame for Python, ML, visualization and exploration of big tabular data at a billion rows per second 🚀
Google Benchmark			A microbenchmark support library

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

Legal note

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

v2.3.1

14 December 2021

🐛 Setting pip options like PIP_USE_DEPRECATED in CIBW_ENVIRONMENT no longer adversely affects cibuildwheel's ability to set up a Python environment (#956)
📚 Docs fixes and improvements

v2.3.0

26 November 2021

📈 cibuildwheel now defaults to manylinux2014 image for linux builds, rather than manylinux2010. If you want to stick with manylinux2010, it's simple to set this using the image options. (#926)
✨ You can now pass environment variables from the host machine into the Docker container during a Linux build. Check out the docs for CIBW_ENVIRONMENT_PASS_LINUX for the details. (#914)
✨ Added support for building PyPy 3.8 wheels. (#881)
✨ Added support for building Windows arm64 CPython wheels on a Windows arm64 runner. We can't test this in CI yet, so for now, this is experimental. (#920)
📚 Improved the deployment documentation (#911)
🛠 Changed the escaping behaviour inside cibuildwheel's option placeholders e.g. {project} in before_build or {dest_dir} in repair_wheel_command. This allows bash syntax like ${SOME_VAR} to passthrough without being interpreted as a placeholder by cibuildwheel. See this section in the docs for more info. (#889)
🛠 Pip updated to 21.3, meaning it now defaults to in-tree builds again. If this causes an issue with your project, setting environment variable PIP_USE_DEPRECATED=out-of-tree-build is available as a temporary flag to restore the old behaviour. However, be aware that this flag will probably be removed soon. (#881)
🐛 You can now access the current Python interpreter using python3 within a build on Windows (#917)

v2.2.2

26 October 2021

🐛 Fix bug in the GitHub Action step causing a syntax error (#895)

v2.2.1

26 October 2021

🛠 Added a config-file option on the GitHub Action to specify something other than pyproject.toml in your GitHub Workflow file. (#883)
🐛 Fix missing resources in sdist and released wheel on PyPI. We've also made some internal changes to our release processes to make them more reliable. (#893, #894)

v2.2.0

22 October 2021

🌟 Added support for musllinux. Support for this new wheel format lets projects build wheels for Linux distributions that use musl libc, notably, Alpine Docker containers. (#768)

Musllinux builds are enabled by default. If you're not ready to build musllinux, add *-musllinux_* to your CIBW_SKIP/skip option. Or, you might have to make some changes to your options - to simplify that process, you can use...
🌟 TOML option overrides! This provides much greater flexibility in configuration via pyproject.toml. (#854)

You can now set build options for any subset of your builds using a match pattern. So, for example, you can customise CPython 3.8 builds with an override on cp38-* or musllinux builds by selecting *musllinux*. Check out the docs for more info on the specifics.
🛠 Added support for building PyPy wheels on macOS 11 CI runners. (#875)
🛠 Setting an empty string for the CIBW_*_IMAGE option will now fallthrough to the config file or cibuildwheel's default, rather than causing an error. This makes the option easier to use in CI build matricies. (#829)
🛠 Support for TOML 1.0 when reading config files, via the tomli package. (#876)

^{Note: This version is not available on PyPI due to some missing resources in the release files. Please use a later version instead.}

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

Joe Rickerby @joerick
Yannick Jadoul @YannickJadoul
Matthieu Darbois @mayeut
Henry Schreiner @henryiii

Credits

cibuildwheel stands on the shoulders of giants.

⭐️ @matthew-brett for multibuild and matthew-brett/delocate
@PyPA for the manylinux Docker images pypa/manylinux
@ogrisel for wheelhouse-uploader and run_with_env.cmd

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

Adding PyPy support

There's probably still a lot to discuss on choosing defaults, option names, build tag names, ... but we can already give this a go and see if we can get the technical part working :)

Cfr. #143

opened by YannickJadoul 99
upgrade macos version for support c++11

macos below 10.6 do not support c++11 features. Next python version of pkg is 10.9. To not break backward compatibility I suggest to manually force 10.9 version

opened by Czaki 90
Universal2 wheels on macOS
Add support for building arm64 and universal2 wheels on macOS 11+.

[x] Building arm64 and universal2 on x86_64 runners using CIBW_ARCHS

[x] Testing universal2 wheels

[x] Docs update

[x] CIBW_ARCHS option

[x] 'How to' build for Apple Silicon, (probably including the nuances around testing)

[x] Fix up CIBW_TEST_SKIP support for specifying parts of universal2 wheels

[x] Examples update?

Closes #473.
opened by joerick 80
Support qemu in GitHub Actions

Looks like it works generally, tests are failing as we need to update expected versions, and some more

We should also discuss if we want to enable all architectures by default, or set the default to only x86/64 architectures, as this may considered a type of "breaking change".

fixes #364

opened by asfaltboy 65
Deterministic builds
An attempt at getting deterministic builds in cibuildwheel.

[x] Pin versions of pip, setuptools, virtualenv etc. installed on macOS and windows

[x] Create separate constraints for python 2

[x] Pin manylinux images (depends on https://github.com/pypa/manylinux/pull/440 ✅)

[x] Pin/vendor/stop using get-pip.py

[x] Add tests

...anything else for that list?

Fix #239
opened by joerick 50
Do not use Python's str.format() for expanding placeholders in commands

Description

Placeholders in command environment variables such as CIBW_BEFORE_BUILD and CIBW_BEFORE_TEST are expanded using Python's str.format():

https://github.com/pypa/cibuildwheel/blob/main/cibuildwheel/util.py#L41

This makes it (nearly) impossible to use curly braces in a command, because a pair of single braces will throw a KeyError exception and a pair of double braces gets interpreted by the GitHub Actions YAML parser. The only option that might work is something ridiculous like {{ '{{' }}.

You should use a different parameter expansion mechanism that doesn't try to expand unknown parameter names.

Build log

No response

CI config

No response

opened by phoerious 46
feat: configuration support
Closes #547.

Design:

tool.cibuildwheel holds options with a structure that exactly matches the environment variables, just with dashes used instead of _ to match TOML style. tool.cibuildwheel.<platform> holds the platform specific commands; these are identical but override the global value if defined and running on that platform. The defaults are defined in cibuildwheel/resources/defaults.toml. Environment variables override the pyproject.toml values, which override the defaults.toml values. An error is thrown if an unexpected option is found inside tool.cibuildwheel or a section based on what was found in the defaults.toml file.

CIBW_PROJECT_REQUIRES_PYTHON does not participate, since it has a canonical location in the pyproject.toml file already, and CIBW_PLATFORM really is only intended to be non-static, so it also does not participate. I have also removed CIBW_OUTPUT_DIR; having that "hidden" in a config file might be confusing? It's already a command line option, an action option, and an environment variable. Also this avoids having a way to specify it per platform.

I have not added a check to see if manylinux-* is in windows/macOS sections (it would do nothing if placed there), or dependency-versions in linux. Those could be added later.

Tables and arrays automatically stringify using sep, so those are recommended but not required for use for things like environment and extras. Strings always behave exactly the same as in the environment variables.

defaults.toml, which serves as the canonical source for defaults, and an example:

[tool.cibuildwheel] build = "*" skip = "" test-skip = "" archs = ["auto"] dependency-versions = "pinned" environment = {} build-verbosity = "" before-all = "" before-build = "" repair-wheel-command = "" test-command = "" before-test = "" test-requires = [] test-extras = [] manylinux-x86_64-image = "manylinux2010" manylinux-i686-image = "manylinux2010" manylinux-aarch64-image = "manylinux2014" manylinux-ppc64le-image = "manylinux2014" manylinux-s390x-image = "manylinux2014" manylinux-pypy_x86_64-image = "manylinux2010" manylinux-pypy_i686-image = "manylinux2010" manylinux-pypy_aarch64-image = "manylinux2014" [tool.cibuildwheel.linux] repair-wheel-command = "auditwheel repair -w {dest_dir} {wheel}" [tool.cibuildwheel.macos] repair-wheel-command = [ "delocate-listdeps {wheel}", "delocate-wheel --require-archs {delocate_archs} -w {dest_dir} {wheel}", ] [tool.cibuildwheel.windows]
opened by henryiii 43
feat: arch specifier for GHA

Follow up to #482, mentioned in #416.

Would it be better to loop through the archs and install them one by one? Not sure what's best with running this container.

opened by henryiii 39
Add support for GitHub Actions
Draft:

[x] basic support (linux, macOS, windows 3.6, 3.7, 3.8)

[x] python 2.7 on windows

[x] python 3.5 on windows

[x] documentation update

Closes #159

Here's a summary of python versions / CI providers used to test cibuildwheel after this PR:

| |2.7 |3.5 |3.6 |3.7 |3.8 | |---------|------------------|----------|---------|-------|------| |windows| AppVeyor |TravisCI | |GitHub|Azure| |linux | TravisCI + CircleCI|TravisCI |CircleCI |TravisCI + GitHub |Azure| |macOS | CircleCI| |TravisCI |CircleCI + GitHub |Azure|
opened by mayeut 37
PyPy virtualenv headers not available

I meet the next bug in PyPy creating virtualenv. File Python.h is not available form virtualenv, which breaks compilation of packages which does not provide PyPy wheels:

https://dev.azure.com/bokota/imagecodecs/_build/results?buildId=565&view=logs&j=9ea3a1cf-027d-5faa-88b4-e0b2b34fabd3&t=77745ba4-e9ed-58b1-0e6d-5824980d22ee&l=249

https://dev.azure.com/bokota/imagecodecs/_build/results?buildId=565&view=logs&j=c436af4d-dd17-5b6b-70ac-85e5b57c9f0c&t=bc0cc3b0-6386-533a-de3c-d01e46ec05cd&l=279

Did You remember who should be called for this? Would we like to add a test that simulates this? I do not want to open heptapod account (which I will forget in short time).

opened by Czaki 35
Repairing Windows wheels

Hello, I am attempting to build a wheel for a C++ Python binding of G'MIC with .dll dependents of a wheel file on Windows MSYS2 with Github Actions. This is for python 3.8 for now. Once I have understood how to "repair" the wheel by including the dependent .dll files into the wheel file, I will proceed to use cibuildwheel most probably. My goal is to iterate on Python versions and use my MSYS2 gcc/g++ and bash commands instead of using Visual Studio. I will give a count of my progress and struggles using cibuildwheel here. I am already using the latter for MacOS Clang builds (though disabled again for now).

Related to #329 and https://github.com/myselfhimself/gmic-py/issues/5 as well as this gmic-py windows-support pull-request

opened by myselfhimself 33
ci: use normal AppVeyor macOS image

use normal AppVeyor macOS image i.e. catalina (10.15) per https://github.com/pypa/cibuildwheel/pull/1372#issuecomment-1369773672 comment.

towards #1372 & #1381

Created a PR cherry-picking @henryiii commits (I think this might be cleaner looking at commit history depending how it would be merged).

Order for merging would be this PR then #1381 and then #1372

opened by mayeut 0
Okay to add arbitrary flags to docker create?

Description

Hi all,

I used your project to create manylinux2014 wheels for a project that uses CUDA. This in itself is quite interesting because I needed to (1) keep a stable ABI on the pybind11 boundaries, (2) not link to any cuda shared libraries, (3) make sure that the wheel size stayed small, and (4) the version of gcc used in manylinux2014 has some incapabilities with. This workflow is definitely worth of sharing more broadly since a lot of CUDA projection adoption is hampered by a lack of pre-built binaries. But that is not the current topic.

Building wheels is perfectly fine for the build process, which uses only CPUs, but I noticed failures when I tried to test because GPUs (which were required by the test cases) on the host machine weren't accessible within the container. The fix, in short, was to add "---gpus all" to the end of the flags here: https://github.com/pypa/cibuildwheel/blob/27fc88e6385a995e61a87ee4b903bed263e6a6e2/cibuildwheel/oci_container.py#L88-L92

I made a quick hack where I added an extra variable (CIBW_EXTRA_DOCKER_CREATE_ARGS, which I set to "--gpus all") to support my use case. Unfortunately, there's no clever way to make docker automatically see from what I've found other than changing the (I would be happy to be corrected). Is this a change that you would be interested in accepting? I can see how allowing users to add arbitrary commands to the docker create command could be a bit fishy (e.g., they could override --volume=/:/host if they were silly), but cibuildwheel does seem like an expert's tools anyway. I would greatly appreciate any feedback form the maintainers.

Build log

No response

CI config

No response

opened by galv 0
Expose major version branch for use with GitHub actions
Description

I use cibuildwheel and dependabot across a few projects. Whenever cibuildwheel makes a minor patch-level change, this creates tons of PRs of the formBump pypa/cibuildwheel from 2.11.1 to 2.11.4 that I don't care for (and which cause days of computation time just to run the CI suite).

I would love to reference cibuildwheel using coarser version specifiers, but this does not work. For example, when I write

- uses: pypa/cibuildwheel@v2

in a GHA file, the build fails with the following error message:

Error: Unable to resolve action `pypa/cibuildwheel@v2`, unable to find version `v2`

It would be lovely if cibuildwheel was installable in this way. Thanks!

Build log

No response

CI config

No response
opened by wjakob 0
musllinux: builds OK, during testing symbols not found

Description

I'm testing out building musl wheel in our project. The builds pass (after a tiny modification), but our tests don't. They go wrong in the tests where we call a secondary binary packages with our wheels (modcc): errors like _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE7reserveEm: symbol not found pop up, indicating a linking error.

Part of our workflow is a post repair-wheel command; we use scikit-build, see also https://github.com/pypa/auditwheel/issues/363

When I remove that custom command, perhaps another hint reveals itself: ImportError: Error loading shared library libstdc++-a9383cce.so.6.0.28: No such file or directory (needed by /tmp/tmp.cPnBgl/venv/lib/python3.7/site-packages/arbor/_arbor.cpython-37m-x86_64-linux-gnu.so). Perhaps we're linking erroneously to libstdc++? I'm not sure if this is our fault, since modcc is separate and perhaps not seen by cibuildwheel, but maybe it should?

Build log

https://github.com/brenthuisman/arbor/actions/runs/3686509310/jobs/6238841756#step:7:6565

CI config

https://github.com/arbor-sim/arbor/blob/master/.github/workflows/ciwheel.yml

opened by brenthuisman 0
Establish predictable removal policy for end-of-life Python versions
With cibuildwheel maturing, I think it would be good to establish a predictable removal policy for end-of-life Python versions. This allows everyone to anticipate the end of wheels for that version, and move on.

Dropping end-of-life Python versions at some point would:

Reduce maintenance burden

Reduce the CI and network burden on the environment 🌳

Signal that the it's time to move on

Of course, with cibuildwheel dropping a Python version, projects that really need beyond end-of-life Python wheels could always keep using an old cibuildwheel version. And existing wheels are still on PyPI after a new cibuildwheel release without support for the EoL version.

My suggestion for a schedule would be something along the lines of:

3 months after EoL: Stop building wheels by default

9 months after EoL: Drop support

With the new 1-year release cadence this would ensure a few cibuildwheel versions in which the end-of-life Python version could be build together with the brand new one. And with 9 months it would be removed before the next one.

Practically, that would look like this:

| Timestep | Python 3.6 | Python 3.7 | Python 3.8 | Python 3.9 | |--------------------------|------------|------------|------------|------------| | End-of-Life | 2021-12-23 | 2023-06-27 | 2024-10-14 | 2025-10-05 | | Stop building by default | 2022-03-23 | 2023-09-27 | 2025-01-14 | 2026-01-14 | | Removing support | 2022-09-23 | 2024-03-27 | 2025-07-14 | 2026-07-14 |

Which would mean for Python 3.6, a one-time catch-up is needed. Then from Python 3.8 onwards, stop building by default in January and drop support in July (just before the release candidate of the next version).

The exact schedule is just a suggestion to start discussion about this. The predictability of the schedule is most important. Curious what everybody thinks!
opened by EwoutH 2

Releases(v2.11.4)

v2.11.4(Dec 24, 2022)
🐛 Fix a bug that caused missing wheels on Windows when a test was skipped using CIBW_TEST_SKIP (#1377)

🛠 Updates CPython 3.11 to 3.11.1 (#1371)

🛠 Updates PyPy 3.7 to 3.7.10, except on macOS which remains on 7.3.9 due to a bug. (#1371)

📚 Added a reference to abi3audit to the docs (#1347)

Source code(tar.gz)
Source code(zip)
v2.11.3(Dec 5, 2022)
✨ Improves the 'build options' log output that's printed at the start of each run (#1352)

✨ Added a friendly error message to a common misconfiguration of the CIBW_TEST_COMMAND option - not specifying path using the {project} placeholder (#1336)

🛠 The GitHub Action now uses Powershell on Windows to avoid occasional incompabilities with bash (#1346)

Source code(tar.gz)
Source code(zip)
v2.11.2(Oct 26, 2022)
🛠 Updates CPython 3.11 to 3.11.0 - final release (#1327)

🛠 Simplify the default macOS repair command (#1322)

🛠 Fix the default MACOSX_DEPLOYMENT_TARGET on arm64 (#1312)

🛠 Hide irrelevant pip warnings on linux (#1311)

🐛 Fix a bug that caused the stdout and stderr of commands in containers to be in the wrong order Previously, stdout could appear after stderr. (#1324)

📚 Added a FAQ entry describing how to perform native builds of CPython 3.8 wheels on Apple Silicon. (#1323)

📚 Other docs improvements

Source code(tar.gz)
Source code(zip)
v2.11.1(Oct 13, 2022)
🛠 Updates to the latest manylinux images, and updates CPython 3.10 to 3.10.8.

Source code(tar.gz)
Source code(zip)
v2.11.0(Oct 13, 2022)
🌟 Adds support for cross-compiling Windows ARM64 wheels. To use this feature, add ARM64 to the CIBW_ARCHS option on a Windows Intel runner. (#1144)

✨ Adds support for building Linux aarch64 wheels on Circle CI. (#1307)

✨ Adds support for building Windows wheels on Gitlab CI. (#1295)

✨ Adds support for building Linux aarch64 wheels under emulation on Gitlab CI. (#1295)

✨ Adds the ability to test cp38-macosx_arm64 wheels on a native arm64 runner. To do this, you'll need to preinstall the (experimental) universal2 version of CPython 3.8 on your arm64 runner before invoking cibuildwheel. Note: it is not recommended to build x86_64 wheels with this setup, your wheels will have limited compatibility wrt macOS versions. (#1283)

🛠 Improved error messages when using custom Docker images and Python cannot be found at the correct path. (#1298)

📚 Sample configs for Azure Pipelines and Travis CI updated (#1296)

📚 Other docs improvements - including more information about using Homebrew for build dependencies (#1290)

Source code(tar.gz)
Source code(zip)
v2.10.2(Sep 25, 2022)
🐛 Fix a bug that caused win32 identifiers to fail when used with --only. (#1282)

🐛 Fix computation of auto/auto64/auto32 archs when targeting a different platform to the one that you're running cibuildwheel on. (#1266)

📚 Fix an mistake in the 'how it works' diagram. (#1274)

Source code(tar.gz)
Source code(zip)
v2.10.1(Sep 18, 2022)
🐛 Fix a bug that stopped environment variables specified in TOML from being expanded. (#1273)

Source code(tar.gz)
Source code(zip)
v2.10.0(Sep 13, 2022)
🌟 Adds support for building wheels on Cirrus CI. This is exciting for us, as it's the first public CI platform that natively supports macOS Apple Silicon (aka. M1, arm64) runners. As such, it's the first platform that you can natively build and test macOS arm64 wheels. It also has native Linux ARM (aarch64) runners, for fast, native builds there. (#1191)

🌟 Adds support for running cibuildwheel on Apple Silicon machines. For a while, we've supported cross-compilation of Apple Silicon wheels on x86_64, but now that we have Cirrus CI we can run our test suite and officially support running cibuildwheel on arm64. (#1191)

✨ Adds the --only command line option, to specify a single build to run. Previously, it could be cumbersome to set all the build selection options to target a specific build - for example, you might have to run something like CIBW_BUILD=cp39-manylinux_x86_64 cibuildwheel --platform linux --archs x86_64. The new --only option overrides all the build selection options to simplify running a single build, which now looks like cibuildwheel --only cp39-manylinux_x86_64. (#1098)

✨ Adds the CIBW_CONFIG_SETTINGS option, so you can pass arguments to your package's build backend (#1244)

🛠 Updates the CPython 3.11 version to the latest release candidate - v3.11.0rc2. (#1265)

🐛 Fix a bug that can cause a RecursionError on Windows when building from an sdist. (#1253)

🛠 Add support for the s390x architecture on manylinux_2_28 (#1255)

Source code(tar.gz)
Source code(zip)
v2.9.0(Aug 11, 2022)
🌟 CPython 3.11 wheels are now built by default - without the CIBW_PRERELEASE_PYTHONS flag. It's time to build and upload these wheels to PyPI! This release includes CPython 3.11.0rc1, which is guaranteed to be ABI compatible with the final release. (#1226)

⚠️ Removed support for running cibuildwheel in Python 3.6. Python 3.6 is EOL. However, cibuildwheel continues to build CPython 3.6 wheels for the moment. (#1175)

✨ Improved error messages when misspelling TOML options, suggesting close matches (#1205)

🛠 When running on Apple Silicon (so far, an unsupported mode of operation), cibuildwheel no longer builds universal2 wheels by default - just arm64. See #1204 for discussion. We hope to release official support for native builds on Apple Silicon soon! (#1217)

Source code(tar.gz)
Source code(zip)
v2.8.1(Jul 18, 2022)
🐛 Fix a bug when building CPython 3.8 wheels on an Apple Silicon machine where testing would always fail. cibuildwheel will no longer attempt to test the arm64 part of CPython 3.8 wheels because we use the x86_64 installer of CPython 3.8 due to its macOS system version backward-compatibility. See #1169 for more details. (#1171)

🛠 Update the prerelease CPython 3.11 to 3.11.0b4. (#1180)

🛠 The GitHub Action will ensure a compatible version of Python is installed on the runner (#1114)

📚 A few docs improvements

Source code(tar.gz)
Source code(zip)
v2.8.0(Jul 5, 2022)
✨ You can now run cibuildwheel on Podman, as an alternate container engine to Docker (which remains the default). This is useful in environments where a Docker daemon isn't available, for example, it can be run inside a Docker container, or without root access. To use Podman, set the CIBW_CONTAINER_ENGINE option. (#966)

✨ Adds support for building py3-none-{platform} wheels. This works the same as ABI3 - wheels won't be rebuilt, but tests will still be run across all selected versions of Python.

These wheels contain native extension code, but don't use the Python APIs. Typically, they're bridged to Python using a FFI module like ctypes or cffi. Because they don't use Python ABI, the wheels are more compatible - they work across many Python versions.

Check out this example ctypes project to see an example of how it works. (#1151)

🛠 cibuildwheel will now error if multiple builds in a single run produce the same wheel filename, as this indicates a misconfiguration. (#1152)

📚 A few docs improvements and updates to keep things up-to-date.

Source code(tar.gz)
Source code(zip)
2.7.0(Jun 17, 2022)
🌟 Added support for the new manylinux_2_28 images. These new images are based on AlmaLinux, the community-driven successor to CentOS, unlike manylinux_2_24, which was based on Debian. To build on these images, set your CIBW_MANYLINUX_*_IMAGE option to manylinux_2_28. (#1026)

🐛 Fix a bug where tests were not being run on CPython 3.11 (when CIBW_PRERELEASE_PYTHONS was set) (#1138)

✨ You can now build Linux wheels on Windows, as long as you have Docker installed and set to 'Linux containers' (#1117)

🐛 Fix a bug on macOS that caused cibuildwheel to crash trying to overwrite a previously-built wheel of the same name (#1129)

Source code(tar.gz)
Source code(zip)
2.6.1(Jun 7, 2022)
🛠 Update the prerelease CPython 3.11 to 3.11.0b3

Source code(tar.gz)
Source code(zip)
2.6.0(May 25, 2022)
🌟 Added the ability to test building wheels on CPython 3.11! Because CPython 3.11 is in beta, these wheels should not be distributed, because they might not be compatible with the final release, but it's available to build for testing purposes. Use the flag --prerelease-pythons or CIBW_PRERELEASE_PYTHONS to test. This version of cibuildwheel includes CPython 3.11.0b1. (#1109)

📚 Added an interactive diagram showing how cibuildwheel works to the docs (#1100)

Source code(tar.gz)
Source code(zip)
2.5.0(Apr 29, 2022)
✨ Added support for building ABI3 wheels. cibuildwheel will now recognise when an ABI3 wheel was produced, and skip subsequent build steps where the previously built wheel is compatible. Tests still will run on all selected versions of Python, using the ABI3 wheel. Check this entry in the docs for more info. (#1091)

✨ You can now build wheels directly from sdist archives, in addition to source directories. Just call cibuildwheel with an sdist argument on the command line, like cibuildwheel mypackage-1.0.0.tar.gz. For more details, check the --help output (#1096)

🐛 Fix a bug where cibuildwheel would crash when no builds are selected and --allow-empty is passed (#1086)

🐛 Workaround a permissions issue on Linux relating to newer versions of git and setuptools_scm (#1095)

📚 Minor docs improvements

Source code(tar.gz)
Source code(zip)
v2.4.0(Apr 2, 2022)
✨ cibuildwheel now supports running locally on Windows and macOS (as well as Linux). On macOS, you'll have to install the versions of Pythons that you want to use from Python.org, and cibuildwheel will use them. On Windows, cibuildwheel will install it's own versions of Python. Check out the documentation for instructions. (#974)

✨ Added support for building PyPy 3.9 wheels. (#1031)

✨ Listing at the end of the build now displays the size of each wheel (#975)

🐛 Workaround a connection timeout bug on Travis CI ppc64le runners (#906)

🐛 Fix an encoding error when reading setup.py in the wrong encoding (#977)

🛠 Setuptools updated to 61.3.0, including experimental support for reading config from pyproject.toml(PEP 621). This could change the behaviour of your build if you have a pyproject.toml with a [project] table, because that takes precedence over setup.py and setup.cfg. Check out the setuptools docs and the project metadata specification for more info.

🛠 Many other dependency updates.

📚 Minor docs improvements

Source code(tar.gz)
Source code(zip)
v2.3.1(Dec 14, 2021)
🐛 Setting pip options like PIP_USE_DEPRECATED in CIBW_ENVIRONMENT no longer adversely affects cibuildwheel's ability to set up a Python environment (#956)

📚 Docs fixes and improvements

Source code(tar.gz)
Source code(zip)
v2.3.0(Nov 26, 2021)
📈 cibuildwheel now defaults to manylinux2014 image for linux builds, rather than manylinux2010. If you want to stick with manylinux2010, it's simple to set this using the image options. (#926)

✨ You can now pass environment variables from the host machine into the Docker container during a Linux build. Check out the docs for CIBW_ENVIRONMENT_PASS_LINUX for the details. (#914)

✨ Added support for building PyPy 3.8 wheels. (#881)

✨ Added support for building Windows arm64 CPython wheels on a Windows arm64 runner. We can't test this in CI yet, so for now, this is experimental. (#920)

📚 Improved the deployment documentation (#911)

🛠 Changed the escaping behaviour inside cibuildwheel's option placeholders e.g. {project} in before_build or {dest_dir} in repair_wheel_command. This allows bash syntax like ${SOME_VAR} to passthrough without being interpreted as a placeholder by cibuildwheel. See this section in the docs for more info. (#889)

🛠 Pip updated to 21.3, meaning it now defaults to in-tree builds again. If this causes an issue with your project, setting environment variable PIP_USE_DEPRECATED=out-of-tree-build is available as a temporary flag to restore the old behaviour. However, be aware that this flag will probably be removed soon. (#881)

🐛 You can now access the current Python interpreter using python3 within a build on Windows (#917)

Source code(tar.gz)
Source code(zip)
v2.2.2(Oct 26, 2021)
🐛 Fix bug in the GitHub Action step causing a syntax error (#895)

Source code(tar.gz)
Source code(zip)
v2.2.1(Oct 26, 2021)
🛠 Added a config-file option on the GitHub Action to specify something other than pyproject.toml in your GitHub Workflow file. (#883)

🐛 Fix missing resources in sdist and released wheel on PyPI. We've also made some internal changes to our release processes to make them more reliable. (#893, #894)

Source code(tar.gz)
Source code(zip)
v2.2.1b1(Oct 26, 2021)
🛠 Added a config-file option on the GitHub Action to specify something other than pyproject.toml in your GitHub Workflow file. (#883)

🐛 Fix missing resources in sdist and released wheel on PyPI. We've made some internal change to our release processes to make them more reliable. (#893, #894)

Source code(tar.gz)
Source code(zip)
v2.2.0(Oct 22, 2021)
🌟 Added support for musllinux. Support for this new wheel format lets projects build wheels for Linux distributions that use musl libc, notably, Alpine Docker containers. (#768)

Musllinux builds are enabled by default. If you're not ready to build musllinux, add *-musllinux_* to your CIBW_SKIP/skip option. Or, you might have to make some changes to your options - to simplify that process, you can use...

🌟 TOML option overrides! This provides much greater flexibility in configuration via pyproject.toml. (#854)

You can now set build options for any subset of your builds using a match pattern. So, for example, you can customise CPython 3.8 builds with an override on cp38-* or musllinux builds by selecting *musllinux*. Check out the docs for more info on the specifics.

🛠 Added support for building PyPy wheels on macOS 11 CI runners. (#875)

🛠 Setting an empty string for the CIBW_*_IMAGE option will now fallthrough to the config file or cibuildwheel's default, rather than causing an error. This makes the option easier to use in CI build matricies. (#829)

🛠 Support for TOML 1.0 when reading config files, via the tomli package. (#876)

Source code(tar.gz)
Source code(zip)
v2.2.0b1(Oct 19, 2021)
Currently in prerelease. The below release notes will be condensed into a single entry on final release.

v2.2.0b1 (19 October 2021)

🌟 TOML option overrides. This provides much greater flexibility in configuration via pyproject.toml.

You can now set build options for any subset of your builds using a match pattern. So, for example, you can customise CPython 3.8 builds with an override on cp38-* or musllinux builds by selecting *musllinux*. Check out the docs for more info on the specifics.

v2.2.0a1 (23 September 2021)

🌟 Added support for musllinux. Support for this new wheel format lets projects build wheels for Linux distributions that use musl libc, notably, Alpine Docker containers.

Musllinux builds are enabled by default. To disable them on your project, add *-musllinux_* to your CIBW_SKIP/skip option. (#768)

🛠 Setting an empty string for the CIBW_*_IMAGE option will now fallthrough to the config file or cibuildwheel's default, rather than causing an error. This makes the option easier to use in CI build matricies. (#829)

Source code(tar.gz)
Source code(zip)
v2.1.3(Oct 6, 2021)
🛠 Updated CPython 3.10 to the 3.10.0 final release.

Source code(tar.gz)
Source code(zip)
v2.2.0a1(Sep 23, 2021)
Currently in prerelease. The below release notes will be condensed into a single entry on final release.

v2.2.0a1 (23 September 2021)

🌟 Added support for musllinux. Support for this new wheel format lets projects build wheels for Linux distributions that use musl libc, notably, Alpine Docker containers.

Musllinux builds are enabled by default. To disable them on your project, add *-musllinux_* to your CIBW_SKIP/skip option. (#768)

🛠 Setting an empty string for the CIBW_*_IMAGE option will now fallthrough to the config file or cibuildwheel's default, rather than causing an error. This makes the option easier to use in CI build matricies. (#829)

Source code(tar.gz)
Source code(zip)
v2.1.2(Sep 14, 2021)
🛠 Updated CPython 3.10 to 3.10.0rc2

📚 Multiple docs updates

🐛 Improved warnings when built binaries are bundled into the container on Linux. (#807)

Source code(tar.gz)
Source code(zip)
v2.1.1(Aug 7, 2021)
✨ Corresponding with the release of CPython 3.10.0rc1, which is ABI stable, cibuildwheel now builds CPython 3.10 by default - without the CIBW_PRERELEASE_PYTHONS flag.

^{Note: v2.1.0 was a bad release, it was yanked from PyPI.}
Source code(tar.gz)
Source code(zip)
v2.0.1(Jul 25, 2021)
📚 Docs improvements (#767)

🛠 Dependency updates, including delocate 0.9.0.

Source code(tar.gz)
Source code(zip)
v2.0.0(Jul 16, 2021)
🌟 You can now configure cibuildwheel options inside your project's pyproject.toml! Environment variables still work of course. Check out the documentation for more info.

🌟 Added support for building wheels with build, as well as pip. This feature is controlled with the CIBW_BUILD_FRONTEND option.

🌟 Added the ability to test building wheels on CPython 3.10! Because CPython 3.10 is in beta, these wheels should not be distributed, because they might not be compatible with the final release, but it's available to build for testing purposes. Use the flag --prerelease-pythons or CIBW_PRERELEASE_PYTHONS to test. (#675) This version of cibuildwheel includes CPython 3.10.0b4.

⚠️ Removed support for building Python 2.7 and Python 3.5 wheels, for both CPython and PyPy. If you still need to build on these versions, please use the latest v1.x version. (#596)

✨ Added the ability to build CPython 3.8 wheels for Apple Silicon. (#704)

🛠 Update to the latest build dependencies, including Auditwheel 4. (#633)

🛠 Use the unified pypa/manylinux images to build PyPy (#671)

🐛 Numerous bug fixes & docs improvements

Source code(tar.gz)
Source code(zip)
v2.0.0a4(Jun 25, 2021)
This release is currently in prerelease. The below release notes will be condensed into a single entry when we do a final release.

v2.0.0a4 (25 Jun 2021)

🌟 Added support for building wheels with build, as well as pip. This feature is controlled with the CIBW_BUILD_FRONTEND option.

v2.0.0a3 (22 Jun 2021)

🌟 You can now configure cibuildwheel options inside your project's pyproject.toml! Environment variables still work of course. Check out the documentation for more info.

v2.0.0a2 (1 Jun 2021)

🌟 Added the ability to test building wheels on CPython 3.10! Because CPython 3.10 is in beta, these wheels should not be distributed, because they might not be compatible with the final release, but it's available to build for testing purposes. Use the flag --prerelease-pythons or CIBW_PRERELEASE_PYTHONS to test. (#675)

✨ Added the ability to build CPython 3.8 wheels for Apple Silicon. (#704)

🛠 Update to the latest build dependencies, including auditwheel 4. (#633)

🛠 Use the unified pypa/manylinux images to build PyPy (#671)

⚠️ Removed support for building Python 2.7 and Python 3.5 wheels, for both CPython and PyPy. If you still need to build on these versions, please use the latest v1.x version. (#596)

Source code(tar.gz)
Source code(zip)