#cibuildwheel

1 messages · Page 2 of 1

mystic leaf
#

Then we could release 3.1

boreal stratus
#

pre-commit?

#

Ah, updates of the CI. I thought there was a cibuildwheel pre-commit that was provided or such

mystic leaf
#

Yes, that's all that is, I like to merge several PRs in a row to save on CI.

drifting dagger
#

@mystic leaf sounds good to me!

mystic leaf
#

I think we should avoid fail-fast. macOS goes out a lot (the iOS tests) and often stops a few good jobs.

drifting dagger
#

mhmm.... perhaps also moving ios to the end of the tests, or a different runner entirely

#

If you wanted to put out a 3.1 release after those PRs that would be good with me! Or I should get to it over the next day or so

mystic leaf
#

I can try, probably by EoD.

#

I like the seperate runner idea. 🙂

mystic leaf
drifting dagger
#

brilliant, thanks henry!

safe skiff
#

a key difference between coverage 7.9.2 and the latest: 7.9.2 used cibuildwheel 2.x on Python 3.9, now I'm using cibuildwheel 3.1.0 on Python 3.11 to make the wheels.

#

I have CIBW_FREE_THREADED_SUPPORT: True in my action. The docs mention it was experimental in 3.13 and in 3.14 it is not. Is that what made the change in which versions got -t builds and which didn't?

safe skiff
#

(rubber-ducking works...) I found the 3.0 release note about the change in environment variables. Trying CIBW_ENABLE now.

mystic leaf
#

Do we not warn/error of the old variable is set?

#

That might be an oversight

safe skiff
#

maybe it's there and I missed it

#

there's so much CI output....

mystic leaf
#

git grep CIBW_FREE_THREADED_SUPPORT doesn't show any code results. I'd rather like making it an error so people know to update the enable. Thoughts on it being an error in 3.1.1 (vs. just adding a warning)?

tropic galleon
#

I think maybe make it an error with clear instructions on how to fix or a docs link. I hit this too when I touched cibuildwheel for cramjam I think?

mystic leaf
#

I think an error better than a wheel disappearing. I won't have a chance to do this for a few hours. I think we should probably get a patch release out soonish, the small Android fix is nice to have too.

tropic galleon
#

out of curiosity, does github retiring macos-13 images have any impact on building x64 mac wheels since there will only be free arm runners

mystic leaf
#

You can cross-compile them, just like you used to be able to cross-compile ARM. Not sure what issues might lurk in that, though. I haven't been doing that yet. At least testing them is easier than the other direction.

terse atlas
#

Hi guys! Need some help for compiling a python module, using cibuildwheel and python 3.12

#

I am basically wrapping OMPL and the Octomap libraries into my own python library - and it is build great, but I am facing this issue just as the auditwheel module is fixing the first generated wheel

# 
Repairing wheel...
      + sh -c 'auditwheel repair -w /tmp/cibuildwheel/repaired_wheel /tmp/cibuildwheel/built_wheel/pathfinder-1.0.0-cp312-cp312-linux_x86_64.whl'
  INFO:auditwheel.main_repair:Repairing pathfinder-1.0.0-cp312-cp312-linux_x86_64.whl
  INFO:auditwheel.main_repair:Wheel is eligible for a higher priority tag. You requested manylinux_2_28_x86_64 but I have found this wheel is eligible for manylinux_2_27_x86_64.
  Traceback (most recent call last):
    File "/usr/local/bin/auditwheel", line 8, in <module>
      sys.exit(main())
               ^^^^^^
    File "/opt/_internal/pipx/venvs/auditwheel/lib/python3.12/site-packages/auditwheel/main.py", line 53, in main
      result: int | None = args.func(args, p)
                           ^^^^^^^^^^^^^^^^^^
    File "/opt/_internal/pipx/venvs/auditwheel/lib/python3.12/site-packages/auditwheel/main_repair.py", line 255, in execute
      out_wheel = repair_wheel(
                  ^^^^^^^^^^^^^
    File "/opt/_internal/pipx/venvs/auditwheel/lib/python3.12/site-packages/auditwheel/repair.py", line 89, in repair_wheel
      raise ValueError(msg)
  ValueError: Cannot repair wheel, because required library "libompl.so.18" could not be located

The basic gist is that I am compiling a module called Pathfinder, by wrapping:

  • Octomap
  • OMPL

Into a .so file, which is the original wheel. Then, auditwheel tries to find the dynamic libraries from OMPL and put them inside the wheel so that it can work

The error occurs as it tries to put the shared lib of the OMPL module into the final wheel

#

The unlinks at the end of CIBW_BEFORE_BUILD_* are a bit ugly, but I don't know what else way I can do it(and even now, it is erroring out)

#

Is there any way I can fix this? I've been at this for the past few days now 😅

#

Infact, if I try to build for MacOS, I get the same issues:

delocate.libsana.DelocationError: Could not find all dependencies.

#

My only point of confusion is that the actual .so is building a-okay(which is dependent on Octomap, OMPL and Pybind11), but then auditwheels, for some reason, doesn't know where the shared .so files for OMPL are. What gives?

boreal stratus
#

Add any LD_LIBRARY_PATH that you used when building those dependencies

terse atlas
boreal stratus
#

Dependsvon how it is built. If you use vcpkg then it's a fair guess

terse atlas
boreal stratus
#

You could also build a container and install those in the system paths

boreal stratus
terse atlas
# boreal stratus Nope. It is a feature we are working on in scikit-build-core

ah, that makes sense. So just to be certain, if I have the installed .so from OMPL in something like

sys@pc-ubuntu:~/Documents/Projects/vcpkg/packages/ompl_x64-linux/lib$ ll
total 11364
drwxrwxr-x 2 sys sys     4096 Jul 20 15:50 ./
drwxrwxr-x 6 sys sys     4096 Jul 20 15:50 ../
lrwxrwxrwx 1 sys sys       13 Jul 20 15:50 libompl.so -> libompl.so.18
-rw-r--r-- 2 sys sys 11625360 Jul 20 15:50 libompl.so.1.7.0
lrwxrwxrwx 1 sys sys       16 Jul 20 15:50 libompl.so.18 -> libompl.so.1.7.0

Then I will do something like export LD_LIBRARY_PATH = "this/path:$LD_LIBRARY_PATH" right?

terse atlas
#

just for a final check, I guess this is what the workflow file would look like?

          CIBW_ENVIRONMENT_LINUX: CMAKE_TOOLCHAIN_FILE="vcpkg/scripts/buildsystems/vcpkg.cmake" LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/project/vcpkg/packages/ompl_x64-linux/lib/"
          CIBW_ENVIRONMENT_MACOS: CMAKE_TOOLCHAIN_FILE="vcpkg/scripts/buildsystems/vcpkg.cmake" DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH://Users/runner/work/path-finding/path-finding/vcpkg/packages/ompl_arm64-osx/lib/"
boreal stratus
terse atlas
#

Yes. I am building them live time, in the build dir, at the cibuildwheel step

boreal stratus
#

The $ I am not sure if it works

terse atlas
# 
      - name: Build wheels
        uses: pypa/cibuildwheel@v3.1.1
        with:
          output-dir: wheelhouse
        env:
          CIBW_BUILD: ..
          CIBW_BEFORE_BUILD_MACOS: ..

          CIBW_BEFORE_BUILD_LINUX: ..
            
          CIBW_ENVIRONMENT_LINUX: ..
          CIBW_ENVIRONMENT_MACOS: ..
          CIBW_SKIP: ...

like this

boreal stratus
terse atlas
#

and in CIBW_BEFORE_BUILD_LINUX and CIBW_BUILD_BEFORE_MACOS, I am installing vcpkg, and downloading/installing everything.

The CMake step works OK, but the repair wheel fails

terse atlas
boreal stratus
boreal stratus
terse atlas
#

No problems! I'm just very confused at this stage because I've been trying to build a multi-platform whl for centuries now 😂

boreal stratus
#

I have an idea. There is a cmake variable to use build-time rpaths for the installation, try setting that to on

terse atlas
#

I'll search

#

OK, think I found it

#

something like this?

set(CMAKE_INSTALL_RPATH "$ORIGIN")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
boreal stratus
#

Yes, but you can pass it via the pyproject.toml instead of hard-coding it

#

And the cmake_install_rpath depends a lot on your wheel structure

terse atlas
terse atlas
boreal stratus
terse atlas
#

Yep, just realized that! Did a bit of a googling and looks like it is @executable_path

terse atlas
boreal stratus
#

I think it's @loader_path. One or the other is technically usable, but it never worked for me

boreal stratus
terse atlas
#

yeah that's fair enough, lol

boreal stratus
#

Distro packaging exposes you to a ton of quirks

drifting dagger
#

I'm gonna be away for a couple of weeks, and quite behind on my notifications already! DM me in discord directly if you need anything!

mystic leaf
#

Enjoy the break! I’ll probably try to push a patch release at some point soon

#

Currently on airplane, but it’s a two day workshop, not anything fun. 🙂

drifting dagger
#

thanks for pushing the patch release!

mystic leaf
#

I likely will push another one soonish for the pip 25.2 windows issue. It only affects people with the unpinned dependencies, but it's pretty bad if so (Windows doesn't work)

static reef
#

@mystic leaf wait what

#

Ah, y'all are calling pip -m install pip -U. Yeah, that's not recommended on Windows exactly because pip can't replace its own entry point when it's called from the same entry point.

#

ERROR: To modify pip, please run the following command:
C:\Users\runneradmin\AppData\Local\Temp\cibw-run-cjkek061\cp39-win_amd64\build\venv\Scripts\python.exe -m pip install --upgrade pip
This is noted in the error message.

#

I agree that it'd've helpful if we'd included a note about this in the changelog.

mystic leaf
#

I hadn't noticed it in the error message, that's good that it's there.

tropic galleon
boreal stratus
#

Isn't aarch64 the minimum common architecture for those? Arm cpu architecture always baffled me

tropic galleon
#

what’s weird is I get back an armv7 abi tag if I run the docker image locally on my mac

#

for the same binary? i think?

boreal stratus
#

With auditwheel?

tropic galleon
#

not sure about auditwheel, I’m just doing python -c “import platform; print(platform.platform())”

#

on CI, I get “Linux-6.11.0-1015-azure-aarch64-with-glibc2.31”

boreal stratus
#

auditwheel is part of the cibuildwheel wheel repair. It might be doing some retagging of the wheel. Dunno if it depends on the actual artifact's tags

tropic galleon
#

on my mac I get “Linux-6.14.10-orbstack-00291-g1b252bd3edea-armv7l-with-glibc2.31”

#

so python itself isn’t calculating the ABI tag the same way

boreal stratus
#

It could be that different containers are used with different --arch flags? Drawing at straws on that discrepancy

visual geyser
#

(does the entry point .exe wrapper actually change between pip versions?)

mystic leaf
#

Yes, the new one avoids a import re, which speeds up small scripts a lot.

#

I've always hated that import, it means things like wrappers around compiled projects are slower than they need to be. uv doesn't add that import, but pip did.

boreal stratus
#

That was actually implemented? Or just for windows?

visual geyser
#

there was a thing in the python-code wrapper that regexes the entry-point's own filename to get rid of windows-specific extensions and such. which would only matter on windows; presumably that logic could occur in the compiled .exe wrapper instead.
actually, do those compiled exes delegate to a python-code wrapper, or do they directly python -c something, or what

#

(I feel like I used to know this...)

mystic leaf
#

It's the little script that looks like this (this one is generated by uv on macOS for pytest's entry point):

#!/Users/henryschreiner/git/scikit-hep/uhi/.venv/bin/python3
# -*- coding: utf-8 -*-
import sys
from pytest import console_main
if __name__ == "__main__":
    if sys.argv[0].endswith("-script.pyw"):
        sys.argv[0] = sys.argv[0][:-11]
    elif sys.argv[0].endswith(".exe"):
        sys.argv[0] = sys.argv[0][:-4]
    sys.exit(console_main())

The pip one used to use re there (on all platforms) , which slows down launching the script unless it also imports re. For compiled wrappers, usually it does not.

#

The compiled shim that gets generated on Windows I think still calls this, but not 100% sure. Though it affects everyone because it's the same wrapper on all platforms.

visual geyser
#

right; my contention is that the wrapper does this because of the Windows compiled shim, because as far as I can discern, sys.argv[0] wouldn't ever match those patterns on other platforms.

#

(or if it somehow did, the modification would be wrong)

mystic leaf
mystic leaf
#

<@&1010930850768113738> Okay with a quick patch release? I'd like to get the Andoid fix out so I can move forward with adding it places.

mystic leaf
#

We could look at adding patchelf first, I suppose

drifting dagger
#

yep happy with a release!

vivid flax
mystic leaf
#

We could wait and pick up that RC. I'm using the SHA anyway for Android just in case there was a second fix needed. (In boost-histogram, the android extension isn't loadable, but I don't know enough to be able to tell what's causing that)

mystic leaf
#

Latest uv supports targetting pyodide. We should see if we can use that.

vivid flax
proven ridge
#

How do you use cibuildwheel with projects that use bazel (and therefore need it in the manylinux container cibuildwheel would use)?

boreal stratus
#

Elegant way would be to make container that inherits the manylinux container and install/build anything you want. Easy/reliable way, install/download the dependencies

#

The base image seems to be all over the place, so probably guess work on what package manager to use

mystic leaf
#

Can you get it with dnf (and apk if you are also building for musllinux)?

mystic leaf
drifting dagger
#

i just approved 🙂

#

i'm a little behind on my notifications but i'll catch up soon!

mystic leaf
#

Would you like me to do the release, or would you like to?

#

I'll go ahead, since it's just a patch release 🙂

south oriole
#

thanks y'all!

#

have y'all released already?

#

pyodide 0.28.2 just came out

mystic leaf
#

No, I'm just writing the changelog now. We could bump that.

south oriole
#

that'll be great. I'll put up a PR quickly

mystic leaf
#

I think you can just trigger the automatic one

south oriole
#

ah, no, that'll bump pyodide-build but not Pyodide

mystic leaf
#

Okay

#

I wonder if we should add that at some point, then?

south oriole
#

yes, that would be useful!

drifting dagger
mystic leaf
#

I think we need an emoji for internal changes

south oriole
#

uv can't do this on its own, though, so we'd need to access the github API for releases. not sure what the best way to do that is nowadays, with all the stringent rate limits for unauthorised requests. :)

mystic leaf
#

I like 🧰. Or 🧪 for tests. Actually I think all the ones I'm struggling to apply an existing emoji to are tests.

south oriole
mystic leaf
#

v3.1.4

19 August 2025

  • ✨ Add a --clean-cache command to clean up our cache (#2489)
  • 🛠 Update Python to 3.14rc2 and other patch version bumps (#2542, #2556)
  • 🛠 Update Pyodide to 0.28.2 (#2562, #2558)
  • 🐛 Fix resolution with pyodide-build when dependency-versions is set (#2548)
  • 🐛 Set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH on Android (#2547)
  • 🐛 Add patchelf dependency for platforms that can build Android wheels (#2552)
  • 🐛 Ignore empty values for CIBW_ARCHS like most other environment variables (#2541)
  • 💼 The color and suggest_on_error argparse options are now default in 3.14rc1+ (#2554)
  • 💼 Use the virtualenv release URL instead of blob URL (should be more robust) (#2555)
  • 🧪 For iOS, lowering to macos-14 is needed for now due to issues with GitHub's runner images (#2557)
  • 🧪 Split out platforms iOS and Android in our tests (#2519)
  • 🧪 Fix and enable doctests (#2546)
  • 📚 Improve our docs on free-threading (#2549)
#

I've updated 3.0+ with the new emoji, and stashed everything for after the pyodide update.

 ### v3.1.3

 _1 August 2025_

+- 🧪 Use pytest-rerunfailures to improve some of our iOS/Android tests (#2527, #2539)
+- 🧪 Remove some GraalPy Windows workarounds in our tests (#2501)
 - 🐛 Fix bug where "latest" dependencies couldn't update to pip 25.2 on Windows (#2537)
-- 🛠 Use pytest-rerunfailures to improve some of our iOS/Android tests (#2527, #2539)
-- 🛠 Remove some GraalPy Windows workarounds in our tests (#2501)
-


 ### v3.1.2
@@ -49,7 +67,7 @@ ### v3.1.0
 - 🛠 Fixed a typo in the 3.9 MUSL riscv64 identifier (`cp39-musllinux_ricv64` -> `cp39-musllinux_riscv64`) (#2490)
 - 🛠 Mistyping `--only` now shows the correct possibilities, and even suggests near matches on Python 3.14+ (#2499)
 - 🛠 Only support one output from the repair step on linux like other platforms; auditwheel fixed this over four years ago! (#2478)
-- 🛠 We now use pattern matching extensively (#2434)
+- 💼 We now use pattern matching extensively (#2434)
 - 📚 We now have platform maintainers for our special platforms and interpreters! (#2481)
drifting dagger
# mystic leaf I think we need an emoji for internal changes

I typically don't include internal changes in the release notes. I figure that users wouldn't need to know it to upgrade, or care even! I think the git/PR history is a better log of changes for maintainers. It's a blurry line though, imo. Some internal changes are interesting, like the argparse changes, so that's nice to include.

#

Thanks for doing the release! 🙂

mystic leaf
#

Done. 🙂

mystic leaf
#

This was cibuildwheel π 🙂

tropic galleon
#

now you have a golden opportunity commit hard to PiVer versioning

mystic leaf
#

Hmm, so next release will be 3.1.4.1 😄

safe skiff
mystic leaf
#

Is it trying to install patchelf? Shouldn’t be on Windows. Can you try the previous patch release?

#

I’m guessing you lock on Linux and then use it on Windows?

safe skiff
#

I build the .pip files on Mac, and got this in the latest diff:

  +patchelf==0.17.2.4
  +    # via cibuildwheel
mystic leaf
safe skiff
#

this is with uv pip compile. Is it able to carry through the conditions?

cunning cradle
safe skiff
#

sorry, i had to be away, and as soon as I left the house, i thought, "--universal?" 😄

safe skiff
#

it worked great, thanks.

mystic leaf
#

FYI, brew upgrade cmake or brew install cmake no longer work on GHA. You have to uninstall cmake first. This will be fixed (and cmake will be 4+) in about a week. (affects building for iOS, where cmake 4+ is required)

tropic galleon
native dirge
#

Hi all, I'm trying to build pyodide wheels with cibuildwheel but when I try and select the build with:

export CIBW_BUILD="cp312-pyodide_wasm32"

I get:

cibuildwheel: error: No build identifiers selected: BuildSelector(build_config='cp312-pyodide_wasm32', skip_config='pp*', requires_python=<SpecifierSet('>=3.9')>, enable=frozenset({<EnableGroup.CPythonFreeThreading: 'cpython-freethreading'>, <EnableGroup.GraalPy: 'graalpy'>, <EnableGroup.PyPyEoL: 'pypy-eol'>, <EnableGroup.PyodidePrerelease: 'pyodide-prerelease'>, <EnableGroup.CPythonPrerelease: 'cpython-prerelease'>, <EnableGroup.PyPy: 'pypy'>}))

What could this be due to?

native dirge
#

Oops I forgot to set CIBW_PLATFORM

#

though if CIBW_PLATFORM defaults to auto, shouldn't it have picked pyodide automatically?

mystic leaf
#

--only does that.

#

BUILD never sets the platform

native dirge
#

Ok thanks for clarifying!

mystic leaf
#

If you want to build both pyodide wheels, you can just set the platform, no need to set build

native dirge
#

Ok thanks!

#

@mystic leaf just to check, is it not possible to upload these wheels to PyPI yet? I get an error:

ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/        
         Binary wheel 'fast_histogram-0.15-cp39-abi3-pyodide_2024_0_wasm32.whl' 
         has an unsupported platform tag 'pyodide_2024_0_wasm32'.
#

(Ah I see that might be expected for now and that https://discuss.python.org/t/pep-776-emscripten-support/84996 is probably the relevant way forward)

Discussions on Python.org
PEP 776: Emscripten Support

I’ve written a draft of a PEP to formalize Emscripten support. I am interested in feedback. It is loosely based on PEP 730 and PEP 738 but we’re in a slightly different situation since the steering council has already approved tier 3 support for Emscripten and our packaging ecosystem is a bit more mature. The main goals are: to have a re...

mystic leaf
#

@tropic galleon FWIW, my main machine is still an Intel mac. Though I know lots of things are going to start dropping when macos-13 goes away. I'm not sure the "x86 is slow" argument holds, as that's true of the runners, but x86 on the much faster AS machines might actually be faster.

#

I'd love for poeple to keep pushing on that PEP 776 thread, we've been stuck without wheel support on PyPI for over a year, while GraalPy, iOS, and Android all got tags quite quickly.

tropic galleon
#

FWIW you should probably be talking to Ralf - he’s been actively working on re-doing the whole numpy security posture and package upload process and this is fallout from that

#

I’m not really involved, just thought I should raise it widely

mystic leaf
#

However, in 1-2 years, when macOS 27 comes out and we have macos-27, then I expect that will be the final nail in the coffin for Intel macs, not having Rosetta.

drifting dagger
#

I wanna get a release out soon with 3.14.0rc3 . It'll have to be a minor, so I think it would be nice to get https://github.com/pypa/cibuildwheel/pull/2597 in before that, tomorrow hopefully. https://github.com/pypa/cibuildwheel/pull/2583 is ready too, if people have time to review.

GitHub
Add GraalPy 25 and remove workarounds for that version. by timfel ...
GitHub
Don't constrain `build-system.requires` with our `dependency-versio...

Fix #2570.
Don&#39;t constrain the versions installed during the package build using dependency-versions. See #2570 for full discussion. AI summary of the change below

This change stops cibuil...

molten arrow
mystic leaf
#

GHA added macos-15-intel, which is the last Intel image

molten arrow
#

At least they added it lol

naive shore
#

Hi there! I'm trying to build https://github.com/pygobject/pycairo/ wheels with cibuildwheel for macOS, fully statically linked for ease of distribution. I'm having the hardest time telling the meson build process to use the brew-installed dependencies somewhere in /opt, presumably because build isolation is tossing out all the env vars. Is there a straightforward way to pass in PKG_CONFIG_PATH or whatever is necessary to make the pkg-config files known to an isolated meson from within cibuildwheel?

drifting dagger
#

i don't know much about meson, but be warned that brew isn't a good place to get your library files for wheel-building

#

brew libraries are typically only compatible with the machine that you're on. for example, they won't support any macOS older that what your CI machine is running

naive shore
#

That's okay for my purposes, this is a company internal wheel where we control the installed macOS version.

drifting dagger
#

oh okay

#

sorry I can't be much help with the meson stuff!

naive shore
#

It's okay, that makes two of us.

tropic galleon
#

@naive shore are you using meson-python as your build backend?

naive shore
#

Yes. pycairo is written to use it.

tropic galleon
#

maybe look at how numpy’s meson config handles finding openblas?

naive shore
#

Hm... good point. I can't be the first to stumble over this. Thanks!

#

(FWIW, I did a hack where I hardcoded all the static libs and where to find them in the meson.build file and it works, so it must be possible somehow)

tropic galleon
#

numpy also uses cibuildwhweel
so you could look at numpy’s wheel-building configuration too

#

somehow we ship openblas libraries in our wheels, I’m foggy on the details though

drifting dagger
naive shore
#

Ah, okay. I was suspecting the PEP517 build isolation was blocking stuff, as I've run into that before in a different project.

#

(I don't fully understand the whole build setup, so maybe I'm just holding it wrong)

naive shore
#

While looking at numpy, I remembered about https://mesonbuild.com/Wrap-dependency-system-manual.html. After a couple hours of fiddling, I haven't gotten anywhere.

I had to go through all dependency meson.build files and kill anything that mentions "install" to prevent meson-py from complaining about how it does not know where into the wheel to put a random compiled library... then cibuildwheel complains that all the dependencies cannot be found while delocating. It's entirely possible that I'm holding meson wrong, though...

naive shore
tropic galleon
naive shore
#

Thanks 👍 we haven't had time yet to look into free threading, so maybe in the future.

honest charm
turbid horizon
honest charm
#

Gotcha. I'm trying it on my workflow now.

turbid horizon
#

Not really “under the hood” — that’s its entire stated goal

#

But yeah

#

It builds wheels for many platforms

honest charm
#

@turbid horizon One last question. Is there a good way to test workflows prior to merging?

turbid horizon
#

Not really

honest charm
mystic leaf
#

You can run on PRs, either a partial matrix or you can only run if the workflow changes. You can also run on workflow dispatch.

#

If you want to run cibuildwheel locally, just do that and don’t run ACT. I would run with --only

honest charm
mystic leaf
#

You can push to TestPyPI if you really want to test that part

#

Usually, we just don’t test the pushing though

honest charm
honest charm
mystic leaf
#

I think the scientific Python cookie cutter pushes to test PyPI by default, don’t remember for sure, though

honest charm
#

I wrote a practice one for a package I was working on that happened to have a tiny workflow.

name: Upload Release Package to PyPI

on:
  release:
    types: [published]
  workflow_dispatch:
    inputs: {}

jobs:
  build_wheels:
    if: github.repository_owner == 'unitaryfoundation'
    name: Build wheels on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        # To build wheels for more platforms, add them here.
        os: [ubuntu-latest, windows-latest, macos-latest]

    steps:
      - name: Check out mitiq
        uses: actions/checkout@v5
        with:
          ref: ${{ github.ref }}

      - name: Build wheels
        uses: pypa/cibuildwheel@v3.1.2

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

  build_sdist:
    if: github.repository_owner == 'unitaryfoundation'
    name: Build source distribution
    runs-on: ubuntu-latest
    steps:
      - name: Check out mitiq
        uses: actions/checkout@v5
        with:
          ref: ${{ github.ref }}

      - name: Build sdist
        run: pipx run build --sdist

      - name: Upload sdist
        uses: actions/upload-artifact@v4
        with:
          name: cibw-sdist
          path: dist/*.tar.gz

  upload_pypi:
    if: github.repository_owner == 'unitaryfoundation'
    needs: [build_wheels, build_sdist]
    runs-on: ubuntu-latest
    environment:
      name: pypi
    permissions:
      id-token: write
    steps:
      - uses: actions/download-artifact@v4
        with:
          # unpacks all CIBW artifacts into dist/
          pattern: cibw-*
          path: dist
          merge-multiple: true

      - name: Publish distribution 📦 to PyPI
        uses: pypa/gh-action-pypi-publish@v1.12.4
        with:
          skip-existing: true
          verbose: true
          print-hash: true
#

I think I got it right? Most of it I practically copied over from Doggo's example.

mystic leaf
#

That looks reasonable

honest charm
#

Thank you so much for the kind review.

#

I'll definitely add it for my own repo in a bit. Mine actually could benefit from this since I have a lot of dependencies.

#

Quick quick question, pip will automatically use one of these generated wheels when you do

pip install sth

depending on your os?

static reef
#

Unless you actually have platform specific code (usually C/C++/Rust code that needs to be compiled), you only should publish the .tar.gz and python3x-any-any .whl your publishing toolchain produces.

boreal wagon
mystic leaf
#

For the most most part, no. For macOS, it is excellent about targeting older versions reliably. That’s one benefit of controlling your ecosystem. My windows, it generally works well too, except for occasionally when something gets introduced like that extra requirement a few years back.

#

I think we have mostly gone to using the latest tag for examples

#

Of course, the architecture matters, and it will matter once they start dropping support for Rosetta in 27 if cross compiling

boreal wagon
#

So if I were to build for Intel or ARM I can just use the latest image provided by GitHub and cibuildwheel will do everything properly?

south oriole
# boreal wagon So if I were to build for Intel or ARM I can just use the latest image provided ...

yes, cibuildwheel automatically sets an appropriate value of the MACOSX_DEPLOYMENT_TARGET environment variable which compilers and CMake adhere to. the value of the environment variable is determined by two factors: whether building for arm/Intel, and the minimum supported deployment target for CPython. this way, intel builds require a minimum of 10.13, and building for silicon requires 11.0.

boreal wagon
#

Cool, thank you!

boreal wagon
#

I opened a PR to add an option to the GitHub action, please let me know what you think 🙂

mystic leaf
#

Though might be an issue for targeting android, which builds on Linux but could use uv (soon, iirc)

#

Also you might get other benefits from installing uv with the action, like caching?

boreal wagon
#

Is there any situation where Linux wouldn't build in a container?

#

Related, where is the logic that installs the build[uv] frontend choice in the containers?

mild plinth
#

I'm looking into https://github.com/pypi/warehouse/issues/18129 and trying to figure out what the main source of wheels with "unsorted" tags is. auditwheel shipped a change in https://github.com/pypa/auditwheel/releases/tag/6.4.0 but it doesn't seem to have much of an effect.

from some random sampling it seems like at least some of these projects are using cibuildwheel, but I'm having a hard time determining what version of cibuildwheel/auditwheel is being used for these (or if cibuildwheel is actually the source of the 'non-compliant' wheel filenames)

mystic leaf
#

I'm pretty sure this has come up before; I think it was because we had to rework a few of our tests when auditwheel 6.4 shipped. That would be related to the manylinux tag.

#

So cibuildwheel 3.0 and newer should produce the sorted tags due to the images they use (unless users pin dead manylinux images)

tropic galleon
#

Is there a way to debug a failing test inside a cibuildwheel build? So far I’ve only been able to trigger a failure inside cibuildwheel on CI.

drifting dagger
#

which platform? linux is pretty easy to recreate because of the docker images, the others are slightly harder to recreate the exact CI scenario. but all platforms can be run locally these days

mystic leaf
#

cibuildwheel 3.3 is out. 🙂

mystic leaf
boreal wagon
#

On Linux, do any environment variables get passed to the container by default like CFLAGS?

mystic leaf
#

No, you have to request them passed through with tool.cibuildwheel.environment-pass

#

We use MkDocs but not material, though, so might not be as ideal for us. And we have custom plugin(s?), the 3.14 color help CLI display is a custom plugin.

#

Ohh, sorry, one environment variable does get passed through by default, SOURCE_DATE_EPOCH

mystic leaf
boreal wagon
mystic leaf
#

pbs is only used for pyodide. I’d be worried about all the patching that’s done for pbs, but they do target a wide macOS range like the official builds. Maybe it would work? But no, currently no option.

boreal wagon
cosmic sable
south oriole
cosmic sable
#

Ah I see

ebon bobcat
#

When does cp315 get added to manylinux? With 3.15.0a2 out, it'd be convenient to setup smoke tests earlier rather than later.

vivid flax
#

3.13 and 3.14 were added just after b1, and 3.15.0b1 is planned for 2026-05-05

mystic leaf
#

Yes, b1. You can use uv or any other tool that uses the Python standalone builds to get a2.

tropic galleon
#

if you use github-actions you can opt into -dev builds with the setup-python action as well

mystic leaf
#

With allow-prereleases: true. Safe to leave on, only affects versions of Python that aren’t out yet.

ebon bobcat
#

Thx, understood (the uv / setup-python solutions). The CI in questions uses the manylinux bundled images, so waiting for b1 seems like the only option without introducing bigger changes.

tropic galleon
#

ah I guess I was fooling myself and I need to write a batch if statement for windows...

tropic galleon
#

sadly I have no idea how to write this in batch correctly...

tropic galleon
#

this seems to do it:

echo {wheel} | findstr /C:\"cp314t\">nul && call || pipx run abi3audit --strict --report {wheel}

Maybe worth adding to the repair-wheel-command docs?

south oriole
#

Perhaps it would make sense to add an option to run abi3audit for abi3 builds built into cibuildwheel itself?

mystic leaf
#

Maybe we should just start doing it always (that is, add it to the default commands). Though we'd have to make one command for both abi3 and regular like above.

drifting dagger
#

yeah, i think we should add it as a general step, with configuration

#

the existence of a {wheels} or {abi3wheels} placeholder in the audit setting could determine if the audit runs at all perhaps

mystic leaf
#

Why does the pip backend work with iOS but not Android? Generally iOS is harder, uv doesn't handle iOS.

compact anchor
drifting dagger
#

i'm thinking of doing a v3.4.0 release later today. Any last minute additions, get em in quick!

mystic leaf
#

I went to work on multi file output eventually, but that’s not a quick addition 🙂

drifting dagger
#

v3.4.0 released!

mystic leaf
#

Made a PR to schemastore with the new schema.

mystic leaf
#

Do we want to enable release immutability? And full length SHA pinning for actions? (In settings). I also will set the default workflow permissions to read only.

south oriole
drifting dagger
#

I think release immutability is a good idea. Not sure what the other two entail but by all means go for it and we can see if anything breaks.

drifting dagger
#

FYI i had to disable the full-length SHA pinning GitHub setting to test an example config in a branch (using bin/run_example_ci_configs) I figured it not a huge loss as zizmor will police that anyway

#

@south oriole i'm not actively working on that audit PR rn if you wanted to get involved!

south oriole
south oriole
drifting dagger
south oriole
#

Interesting

#

I had no idea one can't fork their own repo!

drifting dagger
#

github set up a redirect when it moved from joerick to pypa

#

but yeah, that redirect only works when there's nothing at joerick/cibuildwheel

south oriole
#

I guess the only way is to create another account, but that's a lot of work for this.

mystic leaf
#

Why did that break using a branch?

#

You could also use someone else’s fork, like I could give you access to mine.

#

But I’m curious to know why it breaks using a branch

drifting dagger
#

oh it didn't, but our example configs use tag pins, and i was testing an example config

mystic leaf
#

Ahh. Okay. IMO just using zizmor is fine since we have a valid reason not to use hashes for everything

south oriole
#

BTW, looks like you both have the "cibuildwheel maintainer" role, I'd love to have it too!

drifting dagger
#

done!

mystic leaf
#

Should we move your name up to a regular maintainer, out of the platform maintainers?

tropic galleon
south oriole
#

maybe it makes sense to keep it in both sections

vivid flax
#

the repo moved under pypa 5 years ago, perhaps it's okay to break joerick/cibuildwheel in the next major release?

there's only about 167 YAML files with uses: joerick/cibuildwheel

I expect a lot of those are inactive, and for others, it's an easy fix

compared to 11.8k for uses: pypa/cibuildwheel

drifting dagger
#

there's also URLs to code, issues and PRs kicking around.. i don't mind keeping the current situation tbh.

#

wow 11.8k is a big number huh

vivid flax
#

cibuildwheel is a great project, thanks all for all your work!

upbeat ravine
#

Which UI allows nowadays

drifting dagger
#

ah interesting! i might experiment with this

south oriole
#

looks like someone is spam-reviewing PRs across repos. they reviewed 133 across 56 repos in april alone, and just did that on one of ours. could we please enable Moderation options --> Code review limits --> "Limit to users explicitly granted read or higher access" option? I will report the user to GitHub in the meantime.

image.png
mystic leaf
#

PEP 783 (pyemscripten tags) was accepted 🙂

south oriole
#

I have a PR already up for it :)

vivid flax
upbeat ravine
#

omg

#

the deadline is quite short...

#

quite sad, I liked their platform

mystic leaf
#

I've got a PR nearly ready to remove it from cibuildwheel

tropic galleon
south oriole
mystic leaf
#

What do people get from spam reviewing?

#

On our side, it’s just a gray checkmark, so I don’t generally care. I only care about green checkmarks. 🙂

south oriole
#

eh, no clue, it just adds noise to my already 300+ github notifications 😅

mystic leaf
#

Especially when it’s on a closed PR

#

I don’t think I get notifications about reviews

south oriole
#

interesting, I think I did because they also commented on the abi3audit PR besides reviewing – I marked that as spam

lament grove
tropic galleon
#

I think you can buy stars on repos, so as long as there’s a market for bot accounts to star repos you’ll see behavior like this

#

that said, I wish github was spending more time on mitigating abuse than migrating to azure, but that’s not my call…

mystic leaf
spice oxide
#

Pick a path that has intersphinx support please.

keen coyote
#

There is only one true path: Sphinx

boreal stratus
spice oxide
#

I’d rather projects just support it and then collaborate on some potentially years-in-the-future generic replacement if necessary

boreal stratus
#

I mean that it is not standardized and currently defined and controlled by sphinx, or am I missing something?

spice oxide
#

I don’t think it has been extended or changed in any way in like a decade

#

but technically true yeah

south oriole
#

@mystic leaf if you don't mind me asking, what are you using to run OpenCode:Kimi-K2.6, and is it as strong as the likes of Sonnet/Opus/etc.? is this something I can experiment with on my macbook pro with an m3 pro chip? :)

mystic leaf
#

I'm running on nrp.ai, which I have access to due to some combination of Princeton, my IRIS-HEP grant, and/or my scikit-build grant. There are quite a few services that offer it, too, since it's open. It's a 1T model, so can't run it on my M5pro. 🙂 I'm really looking forward to trying Qwen 4.6 27TB though, that came out this morning locally, though! Looks like it went up about an hour ago on ollama.

#

I think you can run a modified version of Kimi with 512 GB, otherwise it's dual 512 GB macs or 8 80GB GPUs.

#

As far as reasoning, hard to say. Its understanding of codebases is excellent. It is a bit slow and likes to think a lot - smidge lazy, too. I've not used Opus, I'd say 4.6 is pretty close to Sonnet. I feel like it's a bit more "I'll do exactly what you tell me" (kimi) vs "I'll innovate" (sonnet, etc). But hard to say. Harness matters too, I've been using Copilot and OpenCode, and a little Pi.

tropic galleon
#

I’m sending in PRs to remove cpython-freethreading from open source cibuildwheel configurations I can find on github search

mystic leaf
#

How many did you find, approx?

tropic galleon
#

~10 or so today

#

going to leave numpy’s in for now

#

I also found a mention in the CPython docs that I sent in a PR for

south oriole
#

we made {project} accessible to the wheel-repair commands recently. can we do it for config-settings commands too? any qualms?

#

I had this need come up today for a project where I did CIBW_CONFIG_SETTINGS_WINDOWS: "setup-args=--cross-file={project}/meson_cross_files/windows-386.ini" and it doesn't seem to expand {project}

mystic leaf
south oriole
south oriole
#

in some places we use utils.cibuildwheel_run(project_dir, single_python=True). it injects CIBW_BUILD like this:

if single_python:
    env["CIBW_BUILD"] = "cp{}{}-*".format(*SINGLE_PYTHON_VERSION)

where SINGLE_PYTHON_VERSION is a variable only defined in that test file. would it make sense to expose single_python to the user via the CLI (and subsequently the action, etc.)? I have use cases where I support multiple Python versions but my wheels don't have a Python ABI tag but do have a platform tag, i.e., py3-none-platform.whl, so I only need to build the wheel once.

my current way to handle this is to just add CIBW_BUILD to a cp312 identifier, but that can always go stale and thus it sounds like it'd be better if we could pick the minimum supported python from pyproject.toml using existing logic, build one wheel, and stop when done.

drifting dagger
#

i'm mega behind on my github notifications, apologies... i'm also away this weekend so it might be a couple weeks before i catch up! at me here if i'm a blocker on anything

south oriole
#

thanks! I updated the pyodide PEP 783 PR to include your and Henry's suggestions, so that's ready for another look.

mystic leaf
drifting dagger
#

Maybe in practice that means we'd release a minor soon with 3.15b1 and the pyodide updates, and hold the rest in your issue for the upcoming major?

#

How does that sound to you?

mystic leaf
#

The pyodide update is why I originally thought we needed a 4.0. We are completely changing the wheels it produces, dropping 3.12 pyodide and older versions of Pyodide can't load the 3.13 wheels we'll now be making

#

Also, we have to drop 3.8 when 3.15 lands, I believe, as manylinux drops 3.8 when it 3.15 lands IIRC.

#

We could put off develwheel, auditing, and maybe the 3.13t drop (unless manylinux drops it, 3.13t and 3.8 were scheduled to drop a couple of days ago, but 3.15rc1 got delayed to today), but maybe that's still enough to call it 4.0?

#

Yes, the PR says "The addition of CPython 3.15 will be done together with the drop of Python 3.8 & 3.13t" - I think that forces our hand, we need to drop 3.8/3.13t with the 3.15 addition

vivid flax
#

3.15b1 has landed! https://discuss.python.org/t/python-3-15-0-beta-1-is-here/107231

Discussions on Python.org
Python 3.15.0 beta 1 is here!

It’s the first beta and feature freeze! This is a beta preview of Python 3.15 Python 3.15 is still in development. This release, 3.15.0b1, is the first of four planned beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support th...

mystic leaf
#

Great! https://github.com/pypa/manylinux/pull/1884 is next. I think we should do at least 3.15, drop 3.13t, 3.8, and the big pyodide change, release 4.0, and push the other changes till 5.0, probably in 12 months, then.

south oriole
#

I am onboard with putting (adding 3.15b1 + dropping 3.8 + 3.13t) + (pyodide pep 783 work) into 4.0, but I would suggest that we find a way to accommodate (audit) and (delvewheel) earlier than 5.0/twelve months, as that's quite a long time from now otherwise. both are pretty useful changes. what would be a way to do so, or is the only way to release 5.0 much earlier than twelve months, as we wouldn't want to break semver? version numbers are free anyway :)

drifting dagger
#

Gotcha. I think since we're forced into doing v4.0 my preference would be to follow your original plan, I.e. including the delvewheel and audit features at the same time.

drifting dagger
#

Let's continue discussion in #2828. But yes, I'm happy for you to lead this one @mystic leaf ! I won't have a huge amount of time for a week or so

south oriole
mystic leaf
#

I might do a 4.0a1 release just to make it easier to access 3.15 & pyemscripten. It's not looking promising to get 4.0 final out before the PyCon Wasm summit on Thursday...

#

(CI seems to be failing with a GraalPy issue)

vivid flax
# mystic leaf (CI seems to be failing with a GraalPy issue)

We have a problem building GraalPy wheels on macOS Intel, maybe related? Upstream have essentially dropped it, maybe time to do so here too?
https://github.com/ultrajson/ultrajson/issues/731#issuecomment-4385967384

GitHub
macOS wheels not building for GraalPy · Issue #731 · ultrajson/ul...

We've temporarily disabled building macOS wheels for GraalPy: #730 This is due to an issue creating virtualenv inside cibuildwheel: Setting up build environment... + /Users/runner/work/_temp/ci...

mystic leaf
#

The issue is pip isn't working with graalpy on Windows. Maybe we should drop Intel macOS graalpy, though. I believe gha is supporting Intel macOS into 2027 2028 at least.

vivid flax
mystic leaf
mystic leaf
drifting dagger
#

hmm. it's not what I expected! But if this is true- "macOS, Windows, iOS, Pyodide, and Android were already passing None for the dependency constraint when creating test virtualenvs. Linux was the only outlier." then i totally get it

#

i would have expected cibuildwheel to use a pinned version of virtualenv to set up test venvs though, just because of repeatability. however it's a nice win to get dependency-constraints out of linux, and if no other platform does it, that's a good enough reason

#

i wonder why none of the other platforms pin it!

mystic leaf
#

Hmm, those get set up differently, from the existing virtualenv installs, so it sort of is pinned - basically a version is downloaded. Looking at the PR, I'm not sure why it was failing when installing tox - doesn't it auto-upgrade if you install something with a different requirement?

drifting dagger
mystic leaf
#

Ahh, interesting, yes I think that would do it.

#

Should we still remove the linux restriction, since it does affect the virtualenv install?

#

Maybe not if we also don't change virtualenv installs based on this setting in other platforms, I think we might not

#

Yes, we don't get newer virtualenv it when latest is used on other platforms

drifting dagger
#

i suppose one way to make it more consistent would be to install virtualenv with the pyz on linux too

#

or see if manylinux could bundle it

mystic leaf
#

Possibly, I'm guessing it's done this way as it's easier to communicate pip calls with the container

#

Shipping in manylinux would be interesting

mystic leaf
#

https://github.com/pypa/cibuildwheel/pull/2850 & https://github.com/pypa/cibuildwheel/pull/2805 and then I think we can do a beta or RC in time for the summit (might do it at the summit...)

GitHub
chore: add Python 3.15 to CI test matrix and classifiers by henryii...

🤖 Human triggerd, AI assisted PR. AI text below. 🤖
Summary

Add Programming Language :: Python :: 3.15 classifier to pyproject.toml
Update the "Max Python" CI test job from 3.14 t...

GitHub
Audit - general approach to auditing wheels with abi3audit default ...

Following on from #2745. I've only sketched out the functionality in documentation form so far - implementation to come.
The idea is that audit commands can specify {abi3wheel} or {wheel} p...

drifting dagger
#

sounds good 🙂

mystic leaf
tropic galleon
#

time to set up 3.15 nightlies…

mystic leaf
south oriole
#

two documentation-only things I think we missed in the rc1 changelog/release notes/process:

  • can we mention somewhere that people shouldn't use the 314.0.0a2 pyodide release (2026 ABI) to upload wheels to PyPI just yet, but the 2025 ABI is fine (that point also needs to change a1 to a2). similar to the cpython beta point
  • the legal note at https://github.com/pypa/cibuildwheel#legal-note now needs delvewheel as well, besides auditwheel and delocate
vivid flax
#

wheels are building fine for ujson and Pillow with v4.0.0rc1, not tested installing. no iOS wheels for 3.15 yet, what's needed there?

mystic leaf
#

I think we need a beeware support package for 3.15, @lavish brook would know more. I'll ask him if I see him again. 🙂

mystic leaf
#

I caught him at PyCon earlier, the problem is that this is all upstream in Python now, so our update script needs to be updated to look in the same place as normal CPython instead of BeeWare. 🙂

vivid flax
mystic leaf
#

Yes, Kimi found it (I did too while it was running) - do you know if it include the Intel simulator? I seem to remember Russell saying that had been dropped.

vivid flax
#

yes, the zip contains ios-arm64 and ios-arm64_x86_64-simulator

lavish brook
#

The support package on Python.org does support intel; the intel support is only dropped on my numpy patch because of some edge case rounding bugs that weren’t worth chasing down.

#

(Given intel support is effectively EOL next year)

mystic leaf
#

@drifting dagger @opal zenith Hi!

heady temple
#

Hi, all!

lament grove
#

Oh, hey, hello there!

glad bay
#

Hey, what's up?

drifting dagger
#

current status 👉 🖱️

unknown.png
#

🙈

#

oh haha

unknown.png
#

maybe i need to be added to pypa as a member first 🙂

drifting dagger
#

@glad bay @lament grove might you be able to add me as a member then I'll try again?

lament grove
#

I'm at $DayJob right now. Ping me in ~8 hours?

drifting dagger
#

👍

glad bay
#

I lack the power for this

lament grove
#

FWIW, I have the relevant access but I'd like to do this properly, mirroring the same permission structure from all the other projects.

drifting dagger
#

no problem! it can wait till later

lament grove
#

In other words, I don't wanna make some stupid mistake that causes pain coz I pressed the wrong button. 😅

glad bay
#

I think only like 4 people have admin rights over PyPA, other maintainers only are admin over their maintained project 👍

drifting dagger
#

of course... thank you! 🙏

feral plaza
#

ask dustin 😊

lament grove
#

@drifting dagger Around?

#

@drifting dagger You should have an invite to join a cibuildwheel team.

#

Ah, I see you've accepted it.

#

Lemme know if you're making the transfer. And if it's useful, hop into #general voice.

drifting dagger
#

Hey pradyunsg! Yes just out at the moment so on my phone

#

Shall I try making the transfer again?

#

Ok I did it!! I selected the cibuildwheel team when transferring

drifting dagger
#

Its official 🎉

image.png
#

Thank you @lament grove !

lament grove
#

Nice!

#

Awesome. I've made @drifting dagger the maintainer of the cibuildwheel team in the GitHub admin side.

#

I'd recommend adding the folks who have the commit bit to cibuildwheel, to a child team named "cibuildwheel Committers".

#

Actually, lemme make that team.

#

Okie all set.

The outer team (@pypa/cibuildwheel-team) is for folks w/ the triage permissions.
The inner team (@pypa/cibuildwheel-committers) is for folks w/ the commit permissions. Everyone in this team also becomes a member of the "outer" team automatically.

The committers get vote in PyPA stuff, and as Dustin noted on discuss.python.org, should request subscription to the mailing list. :)

#

You should be able to invite people -- Feel free to add the relevant folks to the relevant teams.

#

If something doesn't work, just @mention me. :)

drifting dagger
#

okay brilliant, thank you @lament grove ! You have been super helpful 🙌. I'm still out at the moment but I will check it out properly later 🙂

lament grove
#

^.^

drifting dagger
#

@lament grove just getting settled with my new abilities. a couple things-

  1. could you add @heady temple (github username @yannickjadoul) as a PyPA member so I can add them to the relevant team?
#

ahem
2) perhaps I need an admin permission on pypa/cibuildwheel-committers? I can add team members to pypa/cibuildwheel-team but not pypa/cibuildwheel-committers

#

sorry for the late message. no great hurry! other than that, all looking good. Now I gotta sort out the CI integrations! 🙂

mystic leaf
#

CI integrations
Ping me once you get that done, have a couple of PRs that need to be restarted. 🙂

#

Will dependabot update joerick/cibuildwheel -> pypa/cibuildwheel? That would be really nice! There are ~251 repos using the action, AFAICT from a search.

#

Which is pretty good since it was not added that long ago

#

Searching for cibuildwheel -> code -> yaml actually does a pretty good job of finding users. 1192 results (probably files?). Now just need it sorted by stars. 🙂

drifting dagger
#

I'm not sure... but hopefully yes. perhaps a version bump would trigger an update?

mystic leaf
#

I've got several repos with daily updates, guess we'll see tomorrow.

#

Triggered a manual dependabot run, nothing happened. So I guess we'll see after the next bump.

lament grove
lament grove
#

Invite sent!

lament grove
#

@drifting dagger should be able to move folks around on the two teams.

drifting dagger
#

thanks again pradyun!

heady temple
#

Now I just need to figure out how to get email notifications for this channel, when the tab is closed

#

(Meanwhile: how did this happen!? All I wanted, a few years back, was a way to make wheels for my project and not deal with how to actually make them 🤨 )

glad bay
#

turns out you were not the only person wanting that! 😄

heady temple
#

Yeah, the danger of OSS, I guess? A few PRs to make my things works, and suddenly @drifting dagger asks me to join his project 😅

#

Anyway, happy to be here, all 🙂

mystic leaf
boreal crystal
#

@mystic leaf is there a documented workflow for using cibuildwheel with mypyc/cythonize easily (im working on a attrs/dataclasses replacements that will need some c speedups)

drifting dagger
#

@boreal crystal I don't know of any documentation / minimal examples but I had a quick look through our examples and https://github.com/deepcharles/ruptures looked like a pretty clean example of a Cython project. henryiii might know more!

drifting dagger
#

@lament grove sorry to bother you again! I'm hooking Appveyor up to cibuildwheel again, and went to look in the settings for the repo to debug. It looks to me that I am missing an admin permission on pypa/cibuildwheel! The repo settings page looks like this - note the missing tabs on the left e.g. Manage access, Webhooks, Integrations etc.

unknown.png
lament grove
#

Do you wanna give all the maintainers the admin bit, or do you want a separate team for it?

drifting dagger
#

all maintainers seems good to me!

lament grove
#

Donezo!

Screenshot_2021-05-21_at_12.40.10_PM.png
drifting dagger
#

👍 awesome thank you!

mystic leaf
#

I'm happy to help once you get to the point you are ready for wheels. It should be quite trivial, I'd think.

mystic leaf
#

Ususally, if it's a well defined, PEP 517-powered package, with Requires-Python set in PEP 621 or setup.cfg, then for GHA:

jobs:
  build_wheels:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-20.04, windows-2019, macos-10.15]

    steps:
      - uses: actions/checkout@v2
      - uses: pypa/cibuildwheel@v1.11.0
      - uses: actions/upload-artifact@v2
        with:
          path: ./wheelhouse/*.whl

should be enough to get the bases covered. Though I'd also activate Universal2 or arm64 for AS (and maybe support at least linux arm). That depends on your target audience.

boreal crystal
#

@glad bay btw, does this integrate with tox in any way yet?

glad bay
#

cibuildwheel itself is a pipeline orchestrator, so IMHO they don't have much in common here 🙂

#

or better said they're orthogonal tools 🙂

mystic leaf
#

I'd agree. cibuildwheel sets up the Python versions specifically for wheel building (using official macOS builds from Python.org, or using manylinux when targeting linux), so it's orthogonal to nox/tox.

#

And it assumes you are on CI, so it's okay to do naughty things, like install to standard system locations (win/macOS target only). 🙂

boreal crystal
#

i want to test against the whhels made on ci using the tox config i use

glad bay
#

cibuildwheel is the opposite of tox/nox; it's purposefully not reproducible builds 😄 those builds are meant to work on the CI only xD

boreal crystal
#

well, i want to use tox to do the test/benchmark commands, and cibuildwheel to make the artifacts before i run the tests

mystic leaf
#

cibuildwheel has built-in test support; it makes sure you are in a new virtualenv and installs and tests from your wheel. But it should be trivial to pick up the artifacts and run on them with tox or something else.

glad bay
#

I'm not aware anyone having something similar yet, but would need to be CI bound - aka you'd use different API for GIthub than Gitlab to pull those wheels

mystic leaf
#

If you wanted to run cibuildwheel from tox, you could, I suppose. You'd want run it from Python 3.6+, but you could.

#

And it would be a session you'd only want to run on CI (though it's actually perfectly safe to run --plat linux anywhere as it uses docker)

boreal crystal
#

id also like to try it local ^^

mystic leaf
#

Pulling from GHA/azure/GitlabCI's artifacts would be interesting.

heady temple
#

Didn't @drifting dagger have a branch/PR/script/... to push temporary commits to try out configurations? Let me look that up

drifting dagger
#

oh yeah I totally forgot about that!

heady temple
#

That's not the same as local, though, but it's still fulfilling a similar function?

drifting dagger
#

probably it could work well as a separate package, like pipx run stash-build

#

might be orthogonal to the cibuildwheel/tox question, though?

heady temple
drifting dagger
#

ah yes, indeed!

lament grove
#

@opal zenith 👋

#

Travis CI is installed on pypa/cibuildwheel. Any specific reason you've requested it to be installed on all repositories on pypa?

glad bay
opal zenith
#

@mystic leaf started to work on this

#

Still a draft, as far as I know, there's one issue with PyPy on windows that still needs to be solved (maybe upgrading to PyPy 7.3.5 will be enough for the issue to go away on its own)

lament grove
feral plaza
#

yeah, it should have something like "N/A"

mystic leaf
#

Technically, 3.8 is both supplied by Apple, and supported by the final regular release of CPython 3.8, but didn't have the necessary bits to cross compile so we can't support it from an Intel runner.

#

I was really excited when a Universal download was supplied, but it didn't work

lament grove
#

Oh, okie.

#

Lemme know if there's any specific phrasing you'd prefer.

#

I've allowed edits from maintainers, so if you wanna push changes directly instead, that works too. :)

mystic leaf
#

See https://github.com/pypa/cibuildwheel/pull/664 and https://github.com/pypa/cibuildwheel/pull/663#discussion_r628731708 - it is missing MACOSX_DEPLOYMENT_TARGET and only supports macOS 11+ instead of 10.9+, like the Python 3.9 one.

GitHub
pin CPython 3.8 installer on macosx10.9 by mayeut · Pull Request #6...

macosx11 installer requires macOS 11+ for CPython 3.8 while macosx11 installer for CPython 3.9+ only requires macOS 10.9+ on x86_64.
c.f. comments in #663

GitHub
[Bot] Update dependencies by github-actions · Pull Request #663 · p...

Update the versions of our dependencies.
PR generated by "Update dependencies" workflow.

mystic leaf
#

I've seen a project that used cibuildwheel but also had a native Python 3.8 job that built Universal or ARM wheels (don't remember which) by hand for macOS 11+. I don't remember where that was, though, does anyone remember what project that was?

#

Nevermind, found it.

mystic leaf
mystic leaf
#

(I tend to bounce back and forth with the button on the very top right of docs pages - it tends to get you to the GitHub repo quickly)

drifting dagger
#

Yeah i guess it needs a rebuild. I'll trigger that now

#

hmm... maybe that's not it...

#

probably a mkdocs thing...

#

good catch!

mystic leaf
#

@drifting dagger the end of my loong comment has a question - should -c config.yaml merge with pyproject.toml or flat-out replace it? And should it have a default? If "replace", then the default could be {project}/pyproject.toml, and if merge, it could be {project}/cibuildwheel.toml, perhaps.

#

("merge" meaning if a key doesn't exist in the -c file, then it comes from pyproject.toml)

mystic leaf
#

2.0.0a2? I know I said numbers are cheap, but what happened to 2.0.0a1? 🙂

lament grove
#

My guess: was built locally, and deemed unworthy for public distribution.

mystic leaf
#

So I'm curious as to the story behind it. 🙂

#

Maybe something to do with the upload to pypi, perhaps, as that was yanked.

drifting dagger
#

I don't know why the GitHub diff doesn't show the changes. ¯_(ツ)_/¯ odd

drifting dagger
#

(Minor comment on the above, I think {package}/pyproject.toml would be correct, rather than {project}, right?)

drifting dagger
mystic leaf
mystic leaf
mystic leaf
drifting dagger
#

hello @mystic leaf - quick question

#

I was just reviewing the pyproject.toml docs, looking at the examples

#

that are looking like this

#

I was just thinking that maybe there is too much [tool.cibuildwheel] currently, what do you think? was thinking I could reduce them to something like this...

#

unless there's something I'm missing?

mystic leaf
#

That's what I asked about earlier, I thought you wanted them for each line. Go with what you find looks best. After seeing both, I think I do like the one per example instead of one per line.

drifting dagger
#

sorry, I misunderstood that question before! Yeah I think keeping just a few where they're needed would be better than one-per-line

mystic leaf
#

FYI, I'm going to be traveling starting tomorrow, so won't be very responsive till next week

drifting dagger
#

no problem, thanks for the heads up! I'm also going to be on holiday next week in the highlands of scotland, not sure if I'll have any signal at all to be honest!

mystic leaf
#

I've got two more open checkboxes on that PR.

#

Nice, that sounds fun 🙂 I'll just be ~5 hours away. Not sure if I'm looking forward to a 5 hour drive with a 3-month old...

#

I've only been exploring around Edinburgh, but I really liked it.

#

The multiline string situation still needs to be looked into. I'm worried that this:

CIBW_BEFORE_BUILD_WINDOWS: >
  C:\something &&
  other-command

will have no clear conversion to TOML. You can't chomp the lines, so it will try to run each line; if command fails, then it won't stop. And you also can't use \ at the end of lines since on Windows you need single quotes no-escapes to write paths normally.

#

(pretend there are more and longer lines than in the example above 🙂 )

drifting dagger
#

yeah. I was wondering if on windows we could do before_build.replace("\n", " && ")...

#

but.... that's going to be horrible for users to debug if there's a missing quote somewhere

mystic leaf
#

I still like allowing lists for commands 🙂

#

Though I'd like to actually test and see what does happen for a normal multiline string.

drifting dagger
mystic leaf
#

Especially on Windows.

drifting dagger
#

on windows, i'm 90% sure that errors are ignored

#

I see things like ```
command_1 || exit \b 1
command_2 || exit \b 1
command_3 || exit \b 1

#

which is even more laborious than the && thing

#

i'm not ruling out the TOML lists by the way

#

just would love to find a solution that works for YAML env vars too

mystic leaf
#

It's less of a problem for YAML, since you can use the > block (I've seen it in several configs)

drifting dagger
#

I notice that Github runners have bash preinstalled on Windows... would it be totally crazy to call the commands using that?

mystic leaf
#

I'd stick with the defaults - otherwise it would be quite surprising, I think

#

It's still an issue for bash, too, it's just easier to set at the top (and not unreasonable to add to all multiline commands)

drifting dagger
#

that's kinda what i was thinking... call the commands like sh -o errexit -c "script"

mystic leaf
drifting dagger
#

yes I think that's a dangerous pattern right there

mystic leaf
#

We need to add a nice multiline example once we have one, I don't think we have any. Currently, with the lists, it would be:

[tool.cibuildwheel]
before-all = [
  'yum install bzip2 -y',
  'pip install --upgrade pip',
]

CIBW_BEFORE_ALL: >
  yum install bzip2 -y &&
  pip install --upgrade pip
#

I'm guessing this also works, but only on unix?

CIBW_BEFORE_ALL: |
  set -o errexit
  yum install bzip2 -y
  pip install --upgrade pip
drifting dagger
#

yeah

mystic leaf
#

Ignore the fact that there's a yum there - the first two would work on windows, but the final one does not.

drifting dagger
#

yeah.

#

..

#

Cool... yeah I'm coming around to your line of thinking then

#

let's go with those formulations

#

(first and second examples above)

#

because I think having something documented that's not a footgun is better than a perfect solution

mystic leaf
#

🙂

#

Okay, can you add a little example like that since you are working on the docs?

drifting dagger
#

yep will do

mystic leaf
#

That smily face ended up bigger than I expected.

drifting dagger
#

I'll try to get these edits pushed today/tomorrow

mystic leaf
#

So final question - Should we disallow "bad" platform settings? manylinux-* in windows/macOS, dependency-versions in linux? It will likely add some complexity for very little benefit? Or is it more than a little benefit?

drifting dagger
#

do you mean setting manylinux-images globally i.e. in [tool.cibuildwheel], or specifically in the e.g. [tool.cibuildwheel.windows] section?

mystic leaf
#

Globally is fine, it's just setting it in a dedicated section.

drifting dagger
#

do we allow unrecognised options? e.g. ```
[tool.cibuildwheel]
non-existent-option = "foo"

mystic leaf
#

Should this be an error:

[tool.cibuildwheel.windows]
manylinux-x64_86-image = 'manylinux1'

We already check for unrecognized sections and options (and as of earlier today, the tests check that too 🙂 )

#

But these are special because they are allowed, just not everywhere. Ideally they should be disallowed, but how much is it worth?

drifting dagger
#

if we are disallowing unrecognized options, I think that ideally, yes we should disallow options in the wrong place too

#

but I haven't seen the implementation yet, I don't know the complexity it might cost us..?

#

no strong opinion - up to you 🙂

#

btw, i remember you asked about synchronising the env-var/pyproject.toml tabs on the docs options page, I think that probably isn't going to work because it would change the height of elements up the page, meaning the content is gonna jump around when they are toggled 😦

#

ahhhhhh i just discovered this is invalid TOML - ```
environment = {
BUILD_TIME="$(date)",
SAMPLE_TEXT="sample text"
}

#

inline tables have to be single line

#

okay that explains why we need an example with the full table syntax

#

sorry @mystic leaf i might have given some confusing feedback about this before!

mystic leaf
#

😢 - I guess they really are meant to be inline!

#

I do like it with the full table syntax, though.

drifting dagger
#

yeah that explains the 'inline' 🙄

mystic leaf
#

Inline tables are intended to appear on a single line. A terminating comma (also called trailing comma) is not permitted after the last key/value pair in an inline table. No newlines are allowed between the curly braces unless they are valid within a value. Even so, it is strongly discouraged to break an inline table onto multiples lines. If you find yourself gripped with this desire, it means you should be using standard tables.

boreal crystal
#

has anyone ever considered something like https://github.com/jart/cosmopolitan/issues/81 <- it seems in theory possible to make linux´windows compatible wheels wit the correct setup, they do have universal linux/bsd/windows binaries working

it may even be possible to have broadly linux + bsd + windows compatible wheels if this is implemented

GitHub
Python native extension module support · Issue #81 · jart/cosmopoli...

First of all, huge kudos for the amazing work on cosmopolitan. While I'm still studying how it works, I hope you can pardon me for asking a noob question here. I was wondering if it&#39...

mystic leaf
#

@drifting dagger The update job is broken

Screen_Shot_2021-06-21_at_12.38.26_PM.png
mystic leaf
drifting dagger
mystic leaf
#

I'm running the update manually, turns out nox -s update_proj didn't work, fixing.

#

Will continue with rebasing the pypa-build PR after the deps are updated.

drifting dagger
#

the update job was working after the pypa switchover, right?

boreal crystal
drifting dagger
#

we seem to have lost the link between the repo and our github app, it's another pypa switchover thing... I think i've fixed it, running another job now...

mystic leaf
#

I thought we had adjusted it after the switch over, but apparently not.

mystic leaf
#

I think we should be able to toss the docs projects update into the weekly update. That might make it easier to add projects to the list, as well, as they will just show up the next week.

mystic leaf
#

Any ideas for what the docs should say for tool.cibuildwheel.build-frontend?

A selector for the build backend to use. Can either be "pip", which will run `python -m pip wheel`, or "build", which will run `python -m build --wheel`.

Anything else we should say about making a choice between pip and #build?

mystic leaf
#

@drifting dagger Can we get another alpha, this one with config support (maybe right after 521, #build support)? The only remaining feature PR listed in the 2.0 plan is 569 (limited API) - @heady temple , do you need help with that? Should it get bumped to a later release? I'm thinking it might interact with 715 (multitagging), which has to come after working on #wheel?

#

Also we could do a 1.12.0 (?) with CPython 3.8 + macOS added?

drifting dagger
#

sure.

drifting dagger
#

I've released a v1.12.0 and a v2.0.0a3. Still had a question on #521, but I'm very happy to do another release once that's in.

mystic leaf
#

I've bumped mypy to 1.12, and have updated boost-histogram's PR and cmake's PR to 2.0.0a3. bh is working fine with the test part in config. Will wait for feedback from @opal zenith on the cmake one, but it was working with the PR, so it should be working with the alpha. MyPy could use the config, I think, but they are pretty disconnected from CI, so will need to wait for release (and dropping 3.5, which they mention finally in the 0.910 release post)

mystic leaf
#

I forgot to update the readme with BUILD_FRONTEND

mystic leaf
mystic leaf
drifting dagger
#

I don't know about the pypa.io one, would probably need some DNS trickery, and I guess we'd need to set up 301 redirects, sounds like a bit of work...

#

not super high on my todo list 😛

mystic leaf
#

(have no idea if it even supports binary wheels 🙂 )

mystic leaf
whole lagoon
#

Would be a great building block for a service that essentially monitors PyPI and builds new wheels from sdists automatically when new architectures and wheel standards are created.

mystic leaf
#

That's actually been created before, but I'd like to make that available directly, see https://github.com/pypa/cibuildwheel/issues/597 . I was rather hoping this would get added to build first, but we probably wouldn't need to piggyback on that - and pulling directly from a URL could be nice - #build woudn't do that even if it could build directly from SDists eventually.

glacial tinsel
#

What would this be different from say have a separate step to fetch the sdist, extract it locally, and pass the extracted directory to cibuildwheel? That seems exceedingly trivial to me (just one curl and unzip call away) and I don’t see the value of it in cibuildwheel directly…

#

Maybe what’s really missing is a GitHub Actions example to do the download/extract part so Hynek (and others) can copy-paste :)

mystic leaf
#

I was considering that, even more so after looking at implementing it, as there are questions like should the current directory's file be in the unzipped dir? Say if you need to inject or override a build script, etc.

It would be really nice though as far as making it feel natural to have a job that runs pipx run build --sdist, then a matrix of jobs that grab that sdist and run cibuildwheel on them. Manually extracting make it feel more hacky.

mystic leaf
#

Also pip wheel <sdist> (and pip wheel <url> ) work AFAICT, so it would be nice to potentially just replace . with the given package/url. Would still need to pull a little info from the SDist, but not much. I'd hope build would support this too eventually, since it already supports building from an SDist, just not explicitly.

#

(Based on pip docs not on testing it)

#

@drifting dagger something seems to be wrong with 2.0.0b1. Haven't figured out what yet.

mystic leaf
glacial tinsel
# mystic leaf I was considering that, even more so after looking at implementing it, as there ...

It would be really nice though as far as making it feel natural to have a job that runs pipx run build --sdist, then a matrix of jobs that grab that sdist and run cibuildwheel on them. Manually extracting make it feel more hacky.

It does, but there’s always a limit to what a single command can do, and keep going back to the “it would be nice to have only one command” reasoning is a recipe of infinite scope creep. I’m probably biased since I went through this too many times, my preference is to make commands that work well together and encourage the user to composite them on their own. FWIW, pip also went through this design change (independent to what I went through); a lot of functionalities were bolted on so people can do things in one command, but eventually that proved impossible since every use case is slightly different and someone’s always going to want a new option to change the behaviour a little bit (your issue on the build directory is an early symptom to this IMO). Now pip is trying to change course and purge all that curfuffle, and now many users are pissed because they now need two pip calls instead of one. It’s easier to tell users to do things in multiple steps when they need to early on than later; the resistance from one command to two is absurdly high for many people, so it’s best (for a tool maintainer’s mental burden) to get them out of that unreasonable pretence as soon as possible.

mystic leaf
drifting dagger
#

thanks for sharing @mystic leaf . I never property checked pybind11 out but that looks hella useful!

drifting dagger
# glacial tinsel > It would be really nice though as far as making it feel natural to have a job ...

I think this is very wise advice - "make commands that work well together and encourage the user to composite them", thank you! I suppose all open source projects go through this process to some degree - while they're young they are finding their niche and new features are easy to add, as they mature, maintenance is more of a burden and maintainers have to start drawing lines and saying 'no' a bit more.

Of course there is still some nuance in each decision - if we come across features that are easy to add and unlikely to need maintenance or extra options, that's a +1. And I believe the user experience is also crucial, and if "encouraging the user to composite them" is actually quite a cumbersome script, that should factor in, too. Or, as Alan Kay says: "Make simple things simple, and complex things possible."

glacial tinsel
drifting dagger
#

Just released cibuildwheel v2.0.0 ! Thanks for all your help with it @mystic leaf, @opal zenith and @heady temple !

minor jewel
#

currently porting https://github.com/twisted/twisted-iocpsupport to the new cibuildwheel: https://github.com/twisted/twisted-iocpsupport/pull/5/checks?check_run_id=3199864242

GitHub
GitHub - twisted/twisted-iocpsupport: Protected Twisted package. A ...

Protected Twisted package. A cython extension for Windows IOCP network related API. It provided the minimal helpers to implement the Twisted IOCP reactor. - GitHub - twisted/twisted-iocpsupport: Pr...

GitHub
use cibuildwheel 2 by graingert · Pull Request #5 · twisted/twisted...

Scope and purpose
Add a few words about why this PR is needed and what is its scope.
Add mentions of things that are not covered here and are planed to be done
in separate PRs.
Remove this section
...

#

what should I set for requires-python here?

#

because the project works fine on python2, but cibuildwheel doesn't make py2 wheels

#

and also people only end up with twisted-iocpsupport if they're installing twisted

drifting dagger
#

so twisted-iocpsupport is requires-python>=2.7, and twisted is >=3.6 ?

#

hmm well I suppose you'd want people installing old versions of twisted to still get a wheel

#

twisted doesn't pin to a specific version of twisted-iocpsupport, so the pip resolver will choose the latest

#

so yeah, I think you'd be better off setting python-requires>=3.6 in your next release

#

that way any users on 2.7 that do pip install twisted will get the latest twisted that supports 2.7, and the latest version of twisted-iocpsupport with a 2.7 wheel

#

btw, another way around this would be to pin a specific version of twisted-iocpsupport in each release of twisted. but that comes with its own pros/cons

minor jewel
#

@drifting dagger I went for just bumping the requires python

#

Like the tgz should still work

#

It just doesn't do anything in py2

#

@drifting dagger what do you think about twisted-iocpsupport releasing a 3.10 wheel?

#

Like if we released it as a pre-release that would be ok right?

#

Oh I can just wait until the 2nd

#

When the RC arrives

#

Also what version should we change this to xD

#

The source code hasn't changed for many years it's just extra wheels

#

So it's really a .post0

drifting dagger
#

@minor jewel yeah officially we wouldn't advise releasing a 3.10 wheel until it's RC

minor jewel
drifting dagger
#

I think the CPython devs said they were aiming for ABI compatibility from 3.10b3 forward

#

but you never know

#

(Python 3.10 RC)

minor jewel
#

But we could release twisted-iocpsupport 1.1.0a0 with a 3.10 wheel?

#

And then release twisted-iocpsupport 1.1.0 after 3.10rc0 is supported

drifting dagger
#

erm, yeah sure you could do an alpha with the 3.10 wheel

#

that's a good idea

#

🙂

minor jewel
#

Cool thanks

drifting dagger
#

nP!

minor jewel
#

Does 3.10 automatically graduate from --pre when 3.10rc0+ is present?

#

Or do I need to upgrade cibuildwheel?

drifting dagger
#

you'll need to upgrade cibuildwheel

minor jewel
#

Ok that makes sense

mystic leaf
#

The RC is due out in about 4 days or so, IIRC. 🙂

minor jewel
mystic leaf
minor jewel
mystic leaf
#

It (at least the tag) was on time 🙂 Manylinux had an issue with it we just glossed over for now, but it seems there was a change since beta 4 that broke manylinux2010.

minor jewel
drifting dagger
#

I'm just doing the updates to support 3.10.0rc1 in cibuildwheel now.

#

p.s. If anyone saw the 2.1.0 release, it's yanked. For some reason I thought that the prerelease status was detected from the version string 🙈 apologies!

minor jewel
drifting dagger
#

v2.1.1 with CPython 3.10.0rc1 is now on PyPI!

minor jewel
#

Nice

tranquil copper
#

\o/

drifting dagger
#

(the cross-compilation aarch64 support PR)

#

on the one hand, this is a powerful feature that would improve the ability for packagers to build aarch64 wheels in reasonable time. I read that some packagers really struggle to build these wheels in emulation because it's just so slow... this would solve that

#

and it's clearly quite thorough work, the result of lots of effort and experimentation

#

so there's lots of positives...

#

but also, it's really pretty complicated. I have no idea what kind of errors users are likely to face while using it, but my gut is telling me there are all sorts of possible hazards with a system like this

#

so it might not be in keeping with cibuildwheel's goal of trying to do the "canonical" good wheel build?

#

...and i'm not confident that such a piece of code would be easy to maintain... at least for me personally.

#

so i'm very torn tbh!

#

perhaps one option could be to polish it up and release it clearly marked as 'experimental' and see what happens when people try to build using it?

mystic leaf
#

There's still a lot to do. If we can get it working in several projects, I think it's safe to add. But there are still several unanswered issues, so it's not ready yet, by any means.

drifting dagger
#

Ah great, I was hoping you'd get a chance to test it on your (pretty substantial) projects @mystic leaf ! I suppose those projects are a pretty good test of the kind of complexities that might arise with a solution like this. But yes, more broadly, I like your mentality... there's still lots of work to do but let's see how it looks when the work is done!

opal zenith
#

I won't have time to dig into this myself until musllinux support is done in auditwheel/manylinux/cibuildwheel. It should be in a couple weeks I think. I'm very much interested in what's being done for cross-compilation support & will look at that when I have some time.
FYI, I saw a new topic pop-up about that: https://discuss.python.org/t/towards-standardizing-cross-compiling/10357

Discussions on Python.org
Towards standardizing cross compiling

I am the maintainer of crossenv, a tool that creates a special virtual environment such that once set up, pip wheel numpy will cross-compile a wheel for a different architecture. While this is definitely a niche tool, it works well enough that it has started to see some interest in various other projects. (The one in particular that made me writ...

mystic leaf
#

FYI, seems like empty MANYLINUX env variables are not working (again?).

mystic leaf
#

Showing possible COVID symptoms, got tested. Could also be Crypto, which my wife currently has. Will be slow on getting the overrides going. Have a first draft, basically no tests, and want to rewrite part of it.

minor jewel
mystic leaf
#

Cryptosporidium

upbeat frigate
#

that makes more sense then me imagining that openssl was giving you similar symptoms to covid

drifting dagger
#

roger that henryiii, also I'm on holiday this week so don't have a huge amount of time to review, so no rush!

drifting dagger
#

Get well soon!

mystic leaf
#

Thanks! I think I'm starting to get better.

mystic leaf
#

Midday tomorrow I should be able to resume properly on overrides.

#

(Not covid, and getting much better, but a little behind on other work because I've been out)

drifting dagger
#

well done Henry. It was interesting to learn about all the other things you do in scikit HEP, too

#

btw, the latest beta for v2.2.0 is out. I'm planning to ship the final release (including muslinux and TOML overrides) on Friday, does that give you enough time to test it on your projects @mystic leaf ?

mystic leaf
#

Sure, the most complex one is already using v2.2.0b1 & overrides (though I should rerun the wheels). I'll need to try a couple more, and I'd ideally like to try at one that I didn't help setup. I'd really have liked to have gotten a new manylinux in, since both pip and pypy updates will potentially affect users too, but TravisCI is a <comment removed>.

#

I'll also probably be doing a blog post for it.

drifting dagger
#

Hmm yes I had forgotten about the pip 21.3 manylinux thing. Is it's worth waiting for that? I'm thinking that we could release as-is, since we don't really have a timeline for the manylinux updates

mystic leaf
#

If version numbers are not expensive, then those two changes likely would warrant a new minor number. Adding new targets, pypy3.8 & musllinux, would be slightly nicer to combine, but not at all critical.

mystic leaf
#

https://iscinumpy.gitlab.io/post/cibuildwheel-2-2-0/ (will advertise more broadly tomorrow)

ISciNumPy
🎡 cibuildwheel 2.2

Another great release from cibuildwheel is just around the corner! There are a
few important additions in this release that you should be aware of, so I’ll
outline the major changes here. We’ll cover the new musllinux wheels, overload
configuration, and incoming changes to pip and pypy. As always, it is
recommended that you pin your cibuildwheel...

#

Let me know if you have any suggestions.

vernal torrent
#

Is it also puzzling why manylinux2014 wheels are not very compatible with Python<3.9

#

And just got the question how dependency wheel with manulinux2014 is compatible with lib that is shipped a manylinux2010? Is it compatible?

drifting dagger
#

v2.2.0 released!

mystic leaf
#

Well, it looks like PyPy might be missing a selector or two, I think we can support it for aarch64 now that we've added it to manylinux, but those are actually missing from cibuildwheel too, the table is still correct.

mystic leaf
#

What I would have written would have been a PSA about manylinux1 support ending at the end of the year (not from cibuildwheel, but rather from manylinux). The reason it's still used quite a bit (70% of our users not long ago) is due to CentOS 7 and 8, as well as Ubuntu 20.18 shipping with Pip 9 by default, which can't load a manylinux image other than manylinux1. So users must upgrade their Pip to use newer images. Oh, and upgrading pip provided by a system package manager is unsupported, do it at your own risk. 😛

#

(The only supported solution would be to create venvs, then upgrade pip in the venv every time you make one. Or avoid using the system Python, which is not a popular choice for Linux users)

mystic leaf
# vernal torrent And just got the question how dependency wheel with manulinux2014 is compatible ...

Depends. If you are trying to build a 2010 wheel and you have a build-time dependency on the 2014 wheel, it won't work, since you can't install a 2014 wheel in the 2010 container. If it's a runtime dependency, then you can do it, but you'll probably have to avoid cibuildwheel's testing step, which will reuse a container matching the one it built in (IIRC). As long as you produce the wheel, it should be fine. But a user can't use your lib without supporting the dependencies's 2014, so building it in 2010 is kind of pointless.

#

(pybind11 has a runtime dependency on NumPy if you add NumPy code, and Cython has a build time dependency on NumPy if you add NumPy code)

vernal torrent
mystic leaf
#

There are no selectors for versions of manylinux. py310-manylinux_x86_64 will build whatever image you specify (2010 by default)

#

There's currently no way to target two versions of manylinux at the same time because there is only a single selector (though I have an idea for that, but I'm waiting for overrides to settle in)

vernal torrent
#

Yep, I would prefer a single selector for everything.

mystic leaf
# 
[tool.cibuildwheel]
manylinux-x86_64-image = "manylinux2014"
manylinux-i686-image = "manylinux2014"

Then py310-manylinux_x86_64 builds manylinux2014. For example. You can use overrides to control what each selector builds, say if you want some selectors (python 3.6-3.9) to be manylinux2010 and some (3.10) to be manylinux2014, for example.

#

So, yes, that table has every known selector in cibuildwheel. 🙂

vernal torrent
#

I know how it works, and yet I still prefer single selector for everything, including manylinux[_\d]+

mystic leaf
#

I have an idea, I'll write it up in the near future. But one thing to keep in mind is that you can use any image - manylinux-i686-image = "manylinux2014" is short for manylinux-i686-image = "quay.io/pypa/manylinux2014_x86_64:2021-10-10-790306f", but you could do skhep/manylinuxgcc-x86_64:latest too (real example).

#

And you usually don't want to build more than two manylinuxs, often one - not all of them.

drifting dagger
#

@mystic leaf just finished my work day so coming online to sort this release issue!

#

thank you for the diagnosis and PRs to fix!

#

I'm gonna merge them both and then try a CI-based release

#

while I'm at it, I'm adding you and @opal zenith as PyPI owners just for redundancy in case we need that one day

mystic leaf
#

He might not be able to accept it within the 3 day window; just ping one of us @opal zenith once you are back and we can retrigger the addition.

mystic leaf
#

Uh-oh. 😦

drifting dagger
#

lol

mystic leaf
#

Missing s

drifting dagger
#

cursed release day. i suppose we are quite close to halloween

mystic leaf
#

True

#

I'll test the PR I just made first. I was rather intending to test the action, but hadn't done it yet. Wish we had a test for the action locally, but a bit tricky to do.

drifting dagger
#

okay. feel free to merge when you're happy and ping me on discord and I'll cut another release

mystic leaf
#

Okay, give me 5 mins to test.

#

Going to avoid a pybind11 release today, tomorrow sounds safer, just in case. 😉

#

Pretty sure it's working, going to wait till I can verify it picked up the config.

#

Yep, manylinux2014 for Python 3.10, that's from the config. I'll merge.

drifting dagger
#

released.

mystic leaf
#

manylinux is finally back in sync across all platforms, so I'm ready to merge the update PR (pypy 7.3.7 & pip 21.3), would like one extra set of eyes, though. 🙂

sharp storm
#

has anyone successfully gotten cibuildwheel to run locally? It works fine in github actions, but I thought it might be nice to tun locally simply for the cross-platform testing.

mystic leaf
#

We run it locally quite often for (targeting) linux; if CI fails a job, for example. (Travis special archs, mostly) I highly recommend using the TOML configuration if you do that, though.

static reef
#

What's the recommended way to use tox under cibuildwheel as the test command? I can tell tox to use a wheel instead of building and installing a sdist but there seems to be no reliable way to get the path to the built wheel? Is using glob expansion the best? I'm worried that old artifacts might get picked.. or is that not a concern?

#

oh... man as I say that I find a reference to the wheel placeholder >.<

drifting dagger
#

@static reef the wheel that cibuildwheel has built is already installed in a venv when your test_command is run. But I'm no expert on tox, so I don't know how to configure tox to just use the environment it's run in, maybe there's a way

static reef
#

the answer AFAIK is that you can't 😦

mystic leaf
#

I ran into this too, wanted to download a universal2 wheel on my M1 and run the test suite on it, but didn't know how to make tox do that. Basically venv_backend="none" in nox. 😄

mystic leaf
feral plaza
#

email dustin

drifting dagger
#

yeah, it seems like it might be a job for an admin—I can't enable it

lament grove
#

What do you need here exactly? I have the admin bit, and am happy to help.

lament grove
mystic leaf
#

Thanks 🙂

lament grove
#

Relevant boxes have been ticked, and Zenodo is enabled for cibuildwheel.

drifting dagger
#

nice one thanks @lament grove !

lament grove
#

You'll only get the archiving and DOI for future releases though, if I'm reading the GitHub docs on this correctly.

drifting dagger
#

maybe there's a way within zenodo to add myself and henryiii? though I don't know if knob flipping will even be required

#

aha! maybe i spoke too soon. now I get this

unknown.png
#

@mystic leaf let me know if a release would be useful for you. we could probably do a .post1 or something if it helps

lament grove
#

IIUC, the NSF grants have been submitted already. though, obviously, @mystic leaf will know more than I would. :)

mystic leaf
#

Yes, grant is in, so no rush at all now. Next time it will be easier / nicer to list it as a product I’ve worked on in the biosketch.

#

Same with pybind11, which I didn’t have time to make a new release for

mystic leaf
drifting dagger
#

that's awesome

static reef
#

wait how did black win 2020, it's just an autoformatter 😄

lament grove
#

Hey, can someone check how the PyPI stats for cibuildwheel have evolved since it moved into the PyPA?

mystic leaf
drifting dagger
#

Sure thing, I'll see if I can get the out over the next couple of days

mystic leaf
#

Okay, no huge rush, just would be nice to have. 🙂

#

Would mentioning the workaround for the setuptools pypy cache collision bug be a good idea for the FAQ?

#

Now that we don't split the pypy job into a separate launch if the images match and both default to manylinux2014, this is more likely to happen in 2.3.0.

#

Anything I have to add to an "example" repo is likely a good candidate for a FAQ entry, I think 🙂

mystic leaf
#

@drifting dagger what do you think about swapping the order of the tabs, so the toml config is first, and users have to toggle to see the environment variable version? Currently it seems we are pushing environment variables as the "default"

lament grove
#

Did we add cibuildwheel to PyPA in the last three months?

drifting dagger
#

@mystic leaf I'll have to get back to you on that, I confess I haven't been following the pypy cache collision bug! Will try to have a read later today

drifting dagger
drifting dagger
#

maybe that's a bad reason haha! I do agree that the pyproject.toml is becoming a better way to configure over the environment variables anyway.

drifting dagger
#

This is package file downloads from PyPI, which for a CI project like ours would correlate with open source activity, so I wonder if the reduction during early 2021 correlates with the easing of lockdowns and open source developers leaving their workstations to go outside?! 🙂

#

*fixed an error in the previous version

unknown.png
glacial tinsel
#

From what I can tell cibuildwheel gained much exposure after the Talk Python To Me episode

drifting dagger
#

ah yes that would have had a big impact, for sure.

#

that was mid-october, so could account for the jump in November downloads. But a better metric would be 'projects using cibuildwheel', rather than package downlaods. Not sure how to get that, though. Maybe sourcegraph could do it?

mystic leaf
#

We added quite a few to our list after the PyPA switch - but some of it could have been due to finding sourcegraph. I'm on the waitlist for the new GitHub search. 🙂

mystic leaf
drifting dagger
#

oh interesting, you're suggesting keeping the env var name as the header, but showing the TOML examples by default

#

I had always assumed they should match for consistency's sake. hm....

mystic leaf
#

No, I'd think the env var name is fine for a header. You'd just have to click to see the env-var example, the TOML example would be the first one shown.

drifting dagger
#

Just released v2.3.1!

mystic leaf
boreal wagon
mystic leaf
#

It is missing (some of) the ARM64 symbols. My immediate guess is you are using an external x86_64 only library, not a universal or ARM64 one, so it's not finding the correct symbols to link in.

#

I'm not sure how well autotools handles cross compilation to ARM64, might be something you have to pass there.

boreal wagon
mystic leaf
#

This week's Python Weekly has cibuildwheel in Interesting Projects, Tools and Libraries 🙂

mystic leaf
#

Setuptools 62.1.0 is a big one for cibuildwheel - pypy and cpython now have different build directories! 🎉

bleak flume
mystic leaf
#

It should be.

mystic leaf
drifting dagger
#

Version 2.5.0 released! With ABI3 support and the sdist feature. Hopefully in time for your talk @mystic leaf 🙂

quiet junco
#

It was.

mystic leaf
boreal wagon
drifting dagger
#

@boreal wagon if you're building an extension that doesn't link in any shared libraries, things Just Work. Otherwise, yes delvewheel is certainly worth a shot, I've heard some good things

static reef
#

I'm trying to convert black's cibuildwheel configuration from using GHA envvars to static configuration, but it honestly feels like a downgrade right now. Is there a decent way of handling options that are optionally extended?

[tool.cibuildwheel]
environment = "BLACK_USE_MYPYC=1 MYPYC_OPT_LEVEL=3 PIP_NO_BUILD_ISOLATION=no"

[tool.cibuildwheel.linux]
environment = "BLACK_USE_MYPYC=1 MYPYC_OPT_LEVEL=3 PIP_NO_BUILD_ISOLATION=no CC=clang CFLAGS='-g0 -v'"

I could just repeat the environment key, but that would be unideal ...

I'm working with https://github.com/ichard26/black-mypyc-wheels/blob/main/.github/workflows/build.yaml

mystic leaf
#

It's an API design issue. We've played around with ideas, but it's been hard to come up with a good API. The main issue is that if you merge them, it becomes really hard to "unset" an environment value. For example, if they merged automatically, then you could remove the duplicated keys:

[tool.cibuildwheel.environment]
BLACK_USE_MYPYC="1"
MYPYC_OPT_LEVEL="3"
PIP_NO_BUILD_ISOLATION="no"

[tool.cibuildwheel.linux.environment]
CC="clang"
CFLAGS="-g0 -v"

Which would be great, but then how would you "unset" one of the values in the general environment if you had to do that? The best we've come up with would be some token value like CIBW_UNSET or something like that. Pretty sure I remember TOML not having a null/None value. (there's a minor backwards incompatibility issue here too if we made the change to the default). (This also might be related to the fact we also want ot have the same API in environment variables, so maybe there was a nice "null", but we couldn't replicate it in environment variable mode)

We've also played around with some method to indicate you want extensions, but it's not been easy to come up with something satisfactory to indicate that you want to extend rather than replace.

#

I wonder if we could handle a special key inherit=true/false (I'd guess a bool is not allowed normally). You'd have to use the dict form, but that'd be okay, since it's more natural there anyway. Though that might complicate the options computation.

#

Trying to remember if I knew black used mypyc...

quiet junco
#

ichard26 is to thank for it's mypyc - 2x performance vs. python in all his testing - There is a blog about it all somewhere

lament grove
drifting dagger
lament grove
#

inherit-from :)

#

Basically, you can have a hyphen -- which I don't think is allowed in env var names.

mystic leaf
#

The problem with = false was that it would have only worked in TOML. There wouldn't be an envvar way to remove variables.

#

Does it really need to be impossible to specify in env var mode? You could use inherit=true, then envvar form could be CIBW_ENVIRONMENT_INHERIT_LINUX=1

drifting dagger
#

we could make it "var = 💣" to destroy an env var? 😉

mystic leaf
#

CIBW_UNSET would be about as safe 😄

#

CIBW_💣

drifting dagger
#

i'm not too worried about the unset case, since it would always be possible to do achieve the result with a different structure of config

mystic leaf
#

If we had a toggle, we could change the default in 3.0 - having it inherit is more natural as long as you have a way to undo it.

#

True

drifting dagger
#

at least, it would fine for the unset to be a TOML-only feature

mystic leaf
#

You'd just have to specify everything in the most specific forms

#

Then it could be false. But then envvar's would always inherit?

drifting dagger
#

no i mean the unset to be TOML-only... not the inherit

#

the inherit should probably be possible from both

#

since I can imagine the env-var inheriting from the config file e.g. CIBW_ENVIRONMENT="$inherit=true ANOTHER_VAR=1"

lament grove
#

FWIW, you can do "$inherit" = true in TOML as well (notice the quotes).

mystic leaf
#

Yes, that's what I meant. Since we control the processing of that string, what about CIBW_ENVIRONMENT_LINUX="val=" unsetting val and being the counterpart to = false in TOML?

#

While CIBW_ENVIRONMENT_LINUX="val=''" would set an empty string.

lament grove
#

CIBW_ENVIRONMENT_LINUX="!eggs ham='spam' "?

quiet junco
#

So side note: Goal here is to make black locally build and in GitHub actions. I tried during PyCon but it tried to build a native wheel and I haven’t got back to learning it yet …

lament grove
#

Or even -eggs :P

#

(guess who is looking at extras syntax)

mystic leaf
#

That would also work. Though I like the similarity between eggs = false and an empty =, since !/-eggs isn't valid in a TOML table.

quiet junco
#

Please note: first time for me playing with mypyc and cibuildwheel so no doubt I’m doing 10 things wrong

mystic leaf
#

CIBW_PROJECT_REQUIRES_PYTHON isn't really needed for 3.6+, but it would be for 3.7+ (assuming it's not somewhere easy to pick up already, like in setup.cfg)

#

You set a few things to default (pinned is the default, for example), but otherwise looks pretty reasonable. Setting manylinux2014 (which is the default) would also automatically pin with cibuildwheel version, but you can manually specify a image tag like you do if you want.

#

I wonder what black[d] - ahh, is that what you need for blackd? 😄

drifting dagger
mystic leaf
#

You are missing build-system.build-backend, FYI

#

So you'll get the legacy builder shim.

mystic leaf
#

Hmm, you are adding black as a requirement? That's odd. I'll try to look into it after teaching today. I think you might want the build from sdist functionality we added in 2.4.0 instead, perhaps?

quiet junco
static reef
#

It's ridiculously long and my energy levels have been all over the place lately, so it's been hard to find the time or motivation to work on it.

quiet junco
#

Ahh all fair. I need to find time to resume learning cibuildwheel and building back locally

thorn shell
#

Is there an established pattern for [re]storing the pip cache? Using github actions with cibuildwheel, and ppc64le wheels aren't available for numpy+pandas, so they have to be rebuilt each time which takes about 890s per version, and seems to be occasionally OOM'ing the runners.

#

I can use the official cache action, but I can't find where cibuildwheel might be (if it does at all) mounting the cache on the host

#

That's actually the timing for the aarch64 packages, ppc64le is 2392.05s 😱

vivid flax
vivid flax
thorn shell
#

I don't believe the docker container's cibuildwheel starts have access to the host pip

#

You wouldn't want it to, different architectures

static reef
mystic leaf
#

@drifting dagger I think the windows docker fix would be good to get out in a patch release too (besides the 3.11 testing fix). I'm pretty happy with a second user verifying the fix, but I can probably verify it today too if needed.

drifting dagger
#

@mystic leaf thanks for reviewing #1138! that PR #1117 makes a lot of sense to me, so yeah let's get that in a patch release too. Probably that would be Friday if not before.

drifting dagger
drifting dagger
#

2.7.0 released! By the way, great work on manylinux_2_28 @opal zenith! Looks like a really good step forward from manylinux_2_24.

mystic leaf
#

Why are there both v2.7.0 and 2.7.0 tags for the last few releases? Dependabot seems to pick different ones for different releases. I just noticed I went from v2.6.0 to 2.7.0, but there's still a proper v2.7.0 that it didn't pick.

drifting dagger
#

huh, that's weird. I'm not sure!

#

I normally try to keep the prefix v2.7.0, not 2.7.0

#

I suspect it's something to do with the github releases link

#

thanks for the report. We'll have to leave the multiple tags there I think, since people will have configs pointing to both. Kinda lucky that dependabot parses them interchangably

mystic leaf
#

FYI, our update job is broken. Can try to look into it (at SciPy)

#

Oh, I see why

drifting dagger
#

Thanks!

upbeat ravine
#

I might be interested in helping out with https://github.com/pypa/cibuildwheel/issues/145
What would be needed for maintainers to consider it as supported? I imagine I would have to write all the same kind of documentation that all other supported CI providers have and at least test whether it works (I'm unsure whether you would also want to have a Cirrus CI configuration for the cibuildwheel repository to test that it works?). Is there anything else that would be needed?

GitHub
Support for Cirrus CI · Issue #145 · pypa/cibuildwheel

Yet another good workhorse. https://cirrus-ci.org/features/ Free for Open Source To support Open Source community Cirrus CI provides Linux, Windows, macOS and FreeBSD services free of charge.

#

It's a cool platform because they allow you to use linux arm64 containers with AWS Graviton2 instances (so native aarch64) and they have macOS M1 runners 😄

mystic leaf
#

That’s interesting! Yep, we need a live test to be able to call it working. I think it’s just that, adding it to the docs on a few places and setting up the CI pipeline to run. I think we have an example of each too (though iirc the examples are the CI test)

#

It could be a tiny bit more involved if any think is incompatible, specifically we don’t have a live M1 runner yet.

bleak flume
upbeat ravine
#

One other cool thing is they allow you to spin up full custom vms (not containers) on Google compute engine from the gcp image you provide, though that's not particularly useful for cibuildwheel 😄

#

I'll look into it in coming days and see how that goes