#cibuildwheel

1 messages Β· Page 1 of 1 (latest)

upbeat ravine
#

some progress have been made, after few small fixes in test files, I managed to get cibuildwheel's test suite running on macOS M1

#

builds for all other systems are failing for now though so there's more work for me to do before I'll be able to finish tinkering with CI configuration :)

upbeat ravine
#

Welp, fixing linux x86 build was easy (just took a while for me to know if it's fixed because the build took 48 minutes πŸ˜„) , Windows and linux aarch64 don't seem as easy to fix but I'll get there

upbeat ravine
upbeat ravine
#

So about Windows, it seems that cibuildwheel (or at least its test suite) currently requires Unix tools (i.e. ones you can optionally install with Git) to be present which is not documented. More specifically, there are tests for command substitution that use echo which on Windows is only a part of shell (cmd/powershell) and it does not have a binary for it, not without Unix tools.

Should this be added as a requirement in the documentation for running locally or would it be preferred to solve it differently in some way?
https://cibuildwheel.readthedocs.io/en/stable/setup/#macos-windows-builds

mystic leaf
#

Could we use python -c instead?

upbeat ravine
#

we could

#

although...

#

actually no, I'm pretty sure tests already depend on there being python executable

#

could use sys.executable ofc

#

either way, some of the test suite depends on python being in the PATH anyhow

#

though there are some test cases that I don't think include PATH in the created subprocess so that may not work on unix if not passing full path to the executable

#

unsure

#

I can check that out later

upbeat ravine
upbeat ravine
#

I opened a draft PR for Cirrus CI support: https://github.com/pypa/cibuildwheel/pull/1191

Aside from the currently not working Linux arm64 (primary reason why it's a draft PR), I would say that it's pretty much ready for review so any input you might have on it is welcome.
There's also one workaround added to the test suite with the Windows build which could be more nicely resolved by what we talked about above as msys2's echo binary has a weird hang issue when USERPROFILE env var is not present. I'll probably look into that soon.

GitHub
Add support for Cirrus CI by jack1142 Β· Pull Request #1191 Β· pypa/c...

Resolves #145
Draft for now as Linux arm64 is currently broken and for now further work waits for the resolution of cirruslabs/cirrus-ci-docs#1034
It should probably be possible to spin up a docker...

#

Links to the build in the PR description are for my fork as PyPA org doesn't have Cirrus CI set up and so there are no builds happening there.

upbeat ravine
#

So I've ran into a bug with testing x86_64 on macOS arm64. cibuildwheel runs Python using Rosetta2 by prefixing the command with arch -x86_64 but in case of shell=True, this doesn't work properly with things like &&/||

#

I don't really know how this can be solved in a good way.

upbeat ravine
upbeat ravine
#

So hey @drifting dagger, about the quoting weirdness with Windows echo... The problem is that Windows's echo command works very differently from typical commands. echo "foo" prints "foo", not foo. This makes it hard to test any of that weird quoting because Windows doesn't have any of that, it pretty much just prints exactly what you put after echo

drifting dagger
#

Ah I see

upbeat ravine
#

I wasn't sure how else to solve this problem if we want to use cmd /C echo honestly

#

might make sense to just skip some of those tests

drifting dagger
#

My goodness this is a can of worms isn't it!

#

Did you try the tests with the existing strange quoting ?

upbeat ravine
#

yeah

#

I can dig out the output

drifting dagger
#

some of those, the ones inside the environment evaluators, the quotes are actually parsed in python by bashlex

#

if i remember correctly...

upbeat ravine
#

maybe going with python -c would make more sense after all, I'm not sure

drifting dagger
#

thanks, taking a look...

upbeat ravine
#

Would have to just replace echo with python -c 'import sys; print(*sys.argv[1:])' and everything after that should presumably just work

drifting dagger
#

it's actually weirder than that, cmd /c echo actually adds double-quotes to arguments with spaces

# 
Python 3.10.5 (tags/v3.10.5:f377153, Jun  6 2022, 16:14:13) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.run(['cmd', '/C', 'echo', 'a string with spaces'])
"a string with spaces"
CompletedProcess(args=['cmd', '/C', 'echo', 'a string with spaces'], returncode=0)
>>> subprocess.run(['cmd', '/C', 'echo', 'a string with spaces', 'word', 'another string with spaces']) 
"a string with spaces" word "another string with spaces"
#

your python -c proposal sounds like it would work though

# 
>>> subprocess.run(['python', '-c', 'import sys; print(*sys.argv[1:])', 'a string with spaces', 'word', 'another string with spaces']) 
a string with spaces word another string with spaces
#

yep. that's the unix echo behavour

#

yeah.. this is good. in this solution, the environment lookups are still in bashlex/bashlex_eval

#

maybe, in the test, define python_echo = 'python -c "import sys; print(*sys.argv[1:])"' and substitute it in via an f-string?

upbeat ravine
#

seems fine to me

#

as long as you're fine with the solution πŸ˜„

drifting dagger
#

yeah. it's okay. it's just a test, after all

#

users can still use echo or whatever works on their CI runners

upbeat ravine
#

thanks for commenting on the issue, saves me the trouble

#

I pushed the changes, we'll see if I haven't made any errors after tests run :P

drifting dagger
#

🀞

upbeat ravine
#

welp, that didn't quite work

#

with Azure

#

guess it has python 2 under python

#

do we want to use python_echo = f'"{sys.executable}" -c "import sys; print(*sys.argv[1:])"'

#

I actually find it somewhat surprising it has python 2 under python because some tests already depend on there being some python under python, guess the tests were lucky enough to not have Python 3 syntax πŸ€”

#

I could also do from __future__ import print_function

drifting dagger
#

sys.executable works!

upbeat ravine
#

wow, things keep getting worse...

#

Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to initialize Python
Python runtime state: preinitialized
https://stackoverflow.com/questions/58997105/fatal-python-error-failed-to-get-random-numbers-to-initialize-python

Stack Overflow
Fatal Python error: failed to get random numbers to initialize Python

Fatal Python error: failed to get random numbers to initialize Python

Environment windows 10, VSC 15

Using CreateProcessA winapi and passing lpenvironment variable to run python with scripts.
when

#

The environment you pass to CreateProcessA must include SYSTEMROOT, otherwise the Win32 API call CryptAcquireContext will fail when called inside python during initialization.

#

so when using echo from Unix tools with a custom env passed, we need USERPROFILE on Cirrus CI but when using python with a custom env, we need SYSTEMROOT πŸ™„

static reef
#

this is a drive-by comment, but holy crap is this silly, all power to you to work through this mess!

#

best of luck!

drifting dagger
#

haha !

#

well... you know, this is really starting to sound like we should extend os.environ when running commands

#

i'm trying a few things...

#

I've pushed a commit. Hopefully that resolves the latest mishap!

upbeat ravine
#

alright

upbeat ravine
#

welp, seems like it failed due to an unrelated issue

#

new pip seems to be having issues

#

or well, pip 22.2, maybe it's fixed by 22.2.1

#

I mean, maybe it's unrelated to pip bump :P

#

yeah no, seems more like PyPI issue apparently

drifting dagger
#

I'm not sure what that failure is all about. according to azure it's passing on windows now so I think we're in the clear! I've restarted that macos test.

static reef
#

Hi folks, I'm looking into upgrading black's mypyc build toolchain which includes cibuildwheel. Currently I'm using macOS 10.15 as the GHA platform for all macOS wheels (x86_64, universal2, and arm64) but that's been deprecated and will be removed soon.

#

The general wisdom I've picked up tells me that it's best to build wheels on the oldest supported platform (within reason) so the wheels are compatible with the most machines possible, but how much does that really matter here? I'd love to make the jump to macOS 12 instead of 11 if I could get away with it.

upbeat ravine
#

It depends on Xcode version

#

not macOS version

static reef
#

ah, and that's where my lack of mac development shows :)

upbeat ravine
#

deployment targets there afaik

#

but I haven't done much mac development so I might be wrong

#

I know that cibuildwheel uses the deployment target thing for specifying minimum macOS to build for so it should presumably work :P

static reef
#

specifying the minimum macOS to build for .. where?

#

I'm really confused, sorry.

upbeat ravine
#

It's done internally so doesn't really matter for you as a user I suppose

#

anyhow, you're safe with choosing macOS 12 on GH Actions because it ships with Xcode 13.4 which supports macOS 10.9 as deployment target

keen coyote
static reef
# upbeat ravine anyhow, you're safe with choosing macOS 12 on GH Actions because it ships with X...

gcc -DNDEBUG -g -fwrapv -O3 -Wall -g0 -I/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/mypyc/lib-rt -Ibuild -I/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -c build/__native_610faff656c4cfcbb4a3.c -o build/temp.macosx-10.9-x86_64-3.6/build/__native_610faff656c4cfcbb4a3.o -O3 -Werror -Wno-unused-function -Wno-unused-label -Wno-unreachable-code -Wno-unused-variable -Wno-unused-command-line-argument -Wno-unknown-warning-option -Wno-unused-but-set-variable
seems like on macOS 10.15, cibuildwheel is already targeting 10.9 so the upgrade should be fine

#

not sure what xcode version it's using, but oh well, I don't really feel like digging into this too deep

upbeat ravine
#

Xcode 14 will probably eventually reach the macOS 12 on GH Actions once it's stable so that might jump it to 10.13 I guess. That can't be an issue on macOS 11 because Xcode can't run on it so that's somewhat of an argument for using that but 10.13 has been EOL for a while too

static reef
#

yeah and I assume macOS users usually keep their machines up to date, more so than Windows users

#

well then, that's pretty old lol

unknown.png
upbeat ravine
#

EOLed in 2020

static reef
#

OK sounds good, I'll try upgrading to macOS 12 then. Not sure mypyc works on it tbh, I've heard there are some issues on ARM but I'll deal with that later (if it's a problem)

upbeat ravine
#

macOS 12 is not ARM

#

it supports ARM but GH doesn't have ARM runners

static reef
#

cibuildwheel supports cross compilation to ARM

upbeat ravine
#

Yeah, I'm just saying that you won't be running on ARM πŸ˜„

static reef
#

Yeah fair point. I don't know whether it's an issue with the build target or the host machine

#

could just be the compiler on ARM is more picky (the issue is that more warnings are issued which breaks the build as -Werror is present)

#

something about unintialized variables never using used or something ...

#

Anyway, I presume it's a similar story on Windows, but instead it's the DLLs the wheels are linked to that determine compatibility.. which is determined by the compiler used.

#

... and on Linux, it really doesn't matter since cibuildwheel will use the manylinux docker images anyhow :)

upbeat ravine
#

or musllinux :)

static reef
#

I'm not compiling mypyc wheels for masl (yet, probably?)

upbeat ravine
#

it's enabled by default so thought that you probably do but I now see that you skip it πŸ˜„

static reef
#

I'm stuck on cibuildwheel 2.3.0 right now too

#

Upgrading breaks the linker search path or something on Linux, probably related to a setuptools upgrade or environment variable update..?

#

I'd like to fix that too.

upbeat ravine
#

does it use the same manylinux images?

#

because the newer cibuildwheel versions also support newer manylinux images

static reef
#

no idea tbh

static reef
#

why does everything in the buildchain seemed to be named VS ?! /lh

static reef
#

that's probably it

upbeat ravine
#

they're both manylinux2014, just a different build version, right?

#

not to say that this can't cause it, I was just expecting it to be failing in a different image "family" entirely πŸ˜„

static reef
# 
    /usr/bin/ld: cannot find crtbeginS.o: No such file or directory
    /usr/bin/ld: cannot find -lgcc
    /usr/bin/ld: cannot find -lgcc_s
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    error: command '/usr/bin/clang' failed with exit code 1
#

Β―_(ツ)_/Β―

boreal wagon
static reef
#

lol

#

I had a nightmare getting my internet connection to work on windows yesterday

molten arrow
#

throughout all of my public school years, we only had apple computers, (until the chromebooks eventually showed up). Everyone used a mac computer. All of the programming classes were on macs, and no one used windows unless you brought your own machine

#

they did/could not update their machines due to aging hardware/lack of time

#

Also, most of these machines are donated/supplemented by apple at discounted prices, so there's quite a lot of schools with older outdated mac machines doing programming on them mmlolbutbadlydrawn

static reef
#

well, thankfully wheel tagging supports specifying which the oldest macOS version supported so it's fine, they'll just get a slower install of black

molten arrow
#

oh nice, that's good

mystic leaf
upbeat ravine
#

aaaand it's available PartyGlasses

upbeat ravine
#

I'll get to updating the PR for Cirrus CI in a few days. For an unknown reason, my account on Cirrus CI got suspended (I'm guessing it was done mistakenly by a computer lol) so I can't really do anything until their support respond anyway.

upbeat ravine
#

Devs at Cirrus CI managed to add another way of running Docker on Linux arm64 before PR adding support to cibuildwheel got merged, awesome! 😎

drifting dagger
#

oooh that's fortunate!

#

it's fast! It runs the aarch64 tests in 21min, versus 32min on Travis and 114min on emulated GHA.

upbeat ravine
#

my first try of running tests was with 8 cores but that was just one minute faster which is negligible difference and allows less concurrent builds to run at the same time

#

but yeah, it sure is fast!

upbeat ravine
#

wow, pip really hates this project, doesn't it

#

always some failure lol

#

no sign that it's content-type this time though

drifting dagger
#

yeah our test process involves a lot of pip invocations... and a lot of trips to PyPI.

upbeat ravine
#

really should try to bump pip's verbosity and run it in cron or sth to try pinpointing these intermittent issues

mystic leaf
#

Yeah, pip fails a lot in cibuildwheel's CI.

upbeat ravine
#

Though on second look, there's a reply saying they can't say anything about GitHub hosted ARM runners so maybe my excitement was a bit pre-emptive :o

opal zenith
# upbeat ravine Regarding Windows ARM runners, they're on GitHub's roadmap apparenly: https://tw...

This can be tracked here: https://github.com/actions/runner-images/issues/6175
The same kind of issue exists for Linux: https://github.com/actions/runner-images/issues/5631
And for macOS (opened in December 2020): https://github.com/actions/runner-images/issues/2187

My hope is that with Azure supporting aarch64 (https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/), we'll see at least Linux aarch64 runners in the coming months. For Windows, it might be trickier depending on Software support (or there will be major differences between x86_64 images and aarch64).

boreal wagon
mystic leaf
#

I really wish those tracebacks were better. AttributeError: module 'hatchling.build' has no attribute 'prepare_metadata_for_build_wheel' is unrelated. Raising a raw Exception is a bit unfriendly, too, I think it should at least be RuntimeError. Ideally, you'd just get the error and no traceback, but that needs something like a error's and warnings PEP for PEP 517. 😦 I'm guessing the real part of the traceback is crtbeginS.o, -lgcc, -lgcc_s are missing?

boreal wagon
#

yes but how are they missing?

feral plaza
#

yep, I have meant to ask in the pip channels

#

cc @glacial tinsel

#

just needs a raises ... from None

#

or to handle outside the exception block

#

alternatively, the error stack can be emptied

glacial tinsel
#

Not sure what the context is, if it’s just a from None change why not file a PR?

feral plaza
upbeat ravine
#

cibuildwheel with Cirrus CI support released, pog

mystic leaf
#

Does anyone know of an example of downloading an SDist from PyPI and building it with cibuildwheel 2.5+? I'm aware of wheelforge, but was looking for a simple example for a blog post.

mystic leaf
#

Posted the article here, can always add an example later if one pops up. https://iscinumpy.dev/post/cibuildwheel-2-10-0/

ISciNumPy.dev
🎑 cibuildwheel 2.10

cibuildwheel 2.10 is out, with some important additions. PEP 517 config
settings added, --only (which has an interesting use in GHA), and Cirrus CI
support (including our first Apple Silicon native runner!) are highlights. We
also support Python 3.11rc2 (the final release candidate!).
We’ve had some fantastic releases of cibuildwheel this year, ...

vivid flax
mystic leaf
#

Thanks! Though, technically, you don't need to specify --platfrom either. πŸ˜„

mystic leaf
#

Added an example of building a setup-python 4.1+ non-leaky composite action to the post, since that's really useful and how cibuildwheel and nox work now. πŸ™‚

drifting dagger
#

I think I might try and create a PR with an idea for how to fix #1271 @mystic leaf . Unless you also have something in progress?

mystic leaf
#

This is all I have:

diff --git a/docs/options.md b/docs/options.md
index 498b15d..c4b9a8c 100644
--- a/docs/options.md
+++ b/docs/options.md
@@ -545,7 +545,7 @@ a table of items, including arrays.
     single values.

 Platform-specific environment variables also available:<br/>
-`CIBW_BEFORE_ALL_MACOS` | `CIBW_BEFORE_ALL_WINDOWS` | `CIBW_BEFORE_ALL_LINUX`
+`CIBW_CONFIG_SETTINGS_MACOS` | `CIBW_CONFIG_SETTINGS_WINDOWS` | `CIBW_CONFIG_SETTINGS_LINUX`


 #### Examples

😳

drifting dagger
#

ah! yep that would be a good one to fix too!

#

πŸ™‚

mystic leaf
#

It seems a little worrisome since the quoting behavior is hard enough, and now it changes based on if it splits. $PATH:/windows loves spaces/bin would have worked before and now would fail, right?

drifting dagger
#

yeh, that would fail

mystic leaf
#

(Before 2.10, of course)

drifting dagger
#

though you could do PATH='"$PATH:/windows loves spaces/bin"' i think

mystic leaf
#

(Not that that's a good thing to do, but still makes it harder to reason about)

drifting dagger
#

I'm also looking at your failed cmake-python-distributions log and it feels to me like something else strange is going on there

mystic leaf
#

I'm just not fond of this working:

PATH=$PATH:/local/bin
PATH=/windows loves spaces/bin

But not this:

PATH=$PATH:/windows loves spaces/bin
#

My original thought with cmake was that musllinux updated. Something changed between 2.9 & 2.10. But the fact it has a quoted argument to me seems suspicious.

drifting dagger
#

that seems bugged to me - why are there there double-quotes in the string?

#

the double-quotes also appear in the printout at the top of the build

unknown.png
#

hm. it also seems like there's an incompatibility between shlex and bashlex somewhere

# 
>>> import shlex
>>> shlex.quote("a string with 'single quotes'")
'\'a string with \'"\'"\'single quotes\'"\'"\'\''
>>> shlex.split(shlex.quote("a string with 'single quotes'"))
["a string with 'single quotes'"]
>>> import bashlex
>>> list(bashlex.split(shlex.quote("a string with 'single quotes'")))
['a string with \'"\'"\'single quotes\'"\'"\'']
#

maybe... we don't actually use bashlex.split anywhere though

drifting dagger
static reef
#

For some reason, it's deciding to prepare metadata without installing any sort of dependencies (as far as I can from the logs) on Windows and macOS ... wat

lament grove
#

You aren't on the latest version of pip over there.

#

Not quite sure why that's the case tho.

static reef
#

I'm using a slightly out of date CIWB version and since CIWB pins the build tools, a slightly out of date pip will be installed and used. I tried the latest CIWB (2.10.2) and it still failed.

#

wait, no I am on CIWB 2.10.2

keen coyote
#

What is the process of testing cibuildwheel config? Like, if I wanted to confirm that the config I set up produces correct wheels. Do I need to set up a special CI job only for that? Or is there some tooling provided?

static reef
# 
[tool.cibuildwheel.environment]
HATCH_BUILD_HOOKS_ENABLE = "1"
MYPYC_OPT_LEVEL = "3"
MYPYC_DEBUG_LEVEL = "0"
# The dependencies required to build wheels with mypyc aren't specified in
# [build-system].requires so we'll have to manage the build environment ourselves.
PIP_NO_BUILD_ISOLATION = "no"
# CPython 3.11 wheels aren't available for aiohttp and building a Cython extension
# from source also doesn't work.
AIOHTTP_NO_EXTENSIONS = "1"`

somehow PIP_NO_BUILD_ISOLATION survived after the hatchling PR

#

I feel so stupid. I'm sorry for wasting everyone's time πŸ˜…

static reef
#

I do neither and simply manually trigger a test run on a personal repository. Black will eventually run CD once a while to make sure it stays functional.

vivid flax
drifting dagger
#

I think it's time for a new release - let's try to get #1296 and #1307 merged today and I'll see if I can get something out this evening/tomorrow

drifting dagger
#

v2.11.0 released πŸš€

mystic leaf
#

@drifting dagger PyInstrument is on Python Bytes right now. πŸ™‚

drifting dagger
#

Oooh neat!

#

Thanks for letting me know

#

Got a link ?

#

Ah I found it

south frost
#

Hey everyone! I'm trying to get cibuildwheel and poetry to work together but for some reason it produces an x86_64 wheel even if I've told it the only arch I want it arm64. I've tried many variations but my current attempt is:

The end result is:
https://github.com/sontek/tfparse/blob/fix-arm64-builds/.github/workflows/release.yml#L31-L60

Which says its going to build arm64 but then I get:

1 wheels produced in 2 minutes:
  tfparse-0.2.0-cp310-cp310-macosx_11_0_x86_64.whl   6,760 kB

https://github.com/sontek/tfparse/actions/runs/3286168035/jobs/5413985192

#

This was working when I was using setup.py so I'm wondering if this is just a limitation of poetry + pyproject.toml?

mystic leaf
#

It's not picking up ARCHFLAGS. That's setuptools specific, but other tools usually should respect it (scikit-build does, for example). Poetry doesn't build native libraries, so what plugin are you using?

#

Ahh, cffi. It needs to respect ARCHFLAGS. If not, maybe you can patch it in in build.py.

drifting dagger
#

v2.11.2 is out. Thanks for the PR sweep today @mystic leaf and @opal zenith !

twilit jetty
#

I think I am running into a similar issue as above building arm64, but without using poetry
my cibuildwheel gha config

name: wheels
on:
  push:
    branches: [cibuildwheel]
  workflow_dispatch:
jobs:
  build_wheels:
    name: Build wheels on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        include:
          - os: ubuntu-latest
          - os: windows-latest
          - os: macos-11
            name: macos-x86_64
            macos_arch: "x86_64"
          - os: macos-11
            name: macos-arm64
            macos_arch: "arm64"
    steps:
      - uses: actions/checkout@v3
      - name: Build wheels
        uses: pypa/cibuildwheel@v2.11.2
        env:
          CIBW_TEST_COMMAND: python -c "import solpos; print(solpos.solpos(2022, 10, 16, 15, 27, 13, 2, 52, 7))"
          CIBW_ARCHS_LINUX: "x86_64 aarch64"
          CIBW_ARCHS_WINDOWS : "AMD64 x86 ARM64"
          CIBW_ARCHS_MACOS: "${{ matrix.macos_arch }}"
          CIBW_SKIP: "pp*"
          CIBW_BUILD: "cp37*"
      - uses: actions/upload-artifact@v3
        with:
          path: ./wheelhouse/*.whl

MacOS with arm64 always fails with cibuildwheel: No build identifiers selected: BuildSelector(build_config='cp37*', skip_config='pp*', requires_python=<SpecifierSet('>=3.7')>, prerelease_pythons=False) e.g. this job: https://github.com/theendlessriver13/solpos/actions/runs/3355984758/jobs/5560683691

upbeat ravine
#

@twilit jetty pretty sure you can only build arm64 wheels for 3.8 or maybe 3.9+

#

Yeah, the table in readme shows 3.8+

#

And no pypy

#

You should be building wheels for all python versions anyway though, right?

#

Rather than limit only to 3.7

#

Requires python should cause it not to build older than 3.7 already

twilit jetty
#

ah, that makes sense. I am only using 3.7 because it's an abi3 wheel. Maybe I'll drop 3.7 then or just don't provide arm64 wheels for it. And/or I need to figure out how to use cp38 on macos-arm64 only and cp37 on all other platforms

upbeat ravine
#

Ah, abi3

#

You can add cp38 macOS arm64 tag, yeah

#

cp38-macosx_arm64

#

Then you would have 3.7 abi3 for all platforms except macOS arm64 and 3.8 abi3 for macOS arm64

twilit jetty
#

great, thank you so much for your help! That works now for MacOS. For Linux and aarch64 however (which according to the table in the README should be supported, also with 3.7) I get this in github actions after it pulled the docker image. It hangs forever and does not continue (using ubuntu-latest).

  ed2221e919b1: Pull complete
  Digest: sha256:d6f5f8ef05bf539bb08971acb844a37246b6d89d32b86a4993f7f779699e18f4
  Status: Downloaded newer image for quay.io/pypa/manylinux2014_aarch64:2022-10-25-fbea779
  WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
  f7950cd39ad28ca3196951e0d2a76aa88c183ae59846fe5e370b9882e81811f1
      + /bin/true
  exec /usr/local/bin/manylinux-entrypoint: exec format error

this seems to be an issue with the cross-architecture ?
i.e. this run: https://github.com/theendlessriver13/solpos/actions/runs/3356374442/jobs/5561395379

upbeat ravine
#

You need to set up QEMU if you want to do cross-architecture builds

#

comes down to adding this step before cibuildwheel step:

      - name: Set up QEMU
        if: runner.os == 'Linux'
        uses: docker/setup-qemu-action@v2
        with:
          platforms: all
#

It forever hanging rather than just erroring out seems like something that should maybe be fixed in cibuildwheel? Assuming it can be.

twilit jetty
#

@upbeat ravine Okay, now I got everything running as wanted to juicebHype . Thank you so much for your great help juicebLove . I am a total beginner when it comes to packaging and providing proper wheels for all platforms and architectures. I wanted to get this right, since I am always a little annoyed by some packages being the last one to provide 3.11 wheels, but the first ones to drop python version that are not EOL yet. With abi3 and cibuildwheel this should never be an issue for me now. Thanks for the great tool!

upbeat ravine
#

happy to help with getting more packages to have wheels available

#

to be clear though, I'm not the author of the tool, that credit falls mostly to Joe Rickerby and few others :)

twilit jetty
#

yes, that was a general "thank you" to everyone who built and contributed (and is most likely also reading this channel) juicebLove

lofty halo
#

hi there, is it possible to build python version-agnostic wheels using cibuildwheel? Because the package is pure-binary and we want to produce wheels like:
foo-0.1.0-py3-none-<platform>.whl, how can I achieve that? thanks in advance.

lament grove
#

You'll need abi3 for that, no?

lofty halo
#

Can I make it compatible with pypy* wheels too?

upbeat ravine
#

Like what ruff does for example

#

Or that package on PyPI which ships nodejs lol

#

If that's the case though, why do you want to use cibuildwheel for this?

lament grove
#

OS matrix

mystic leaf
#

Don't use ABI3 if it's really not Python dependent. You'll need to either retag the wheels (I have a PR to wheel for this), or scikit-build-core natively supports this via config. You still probably want manylinux builds, etc, from cibuildwheel to ensure it's distributable.

drifting dagger
#

It does the native code with ctypes

mystic leaf
#

Importing from wheel is very much unsupported, wheel's API is entirely private (and being completely redesigned).

vivid flax
naive shore
#

hi! i want to use ccache to cibuild a wheel, but setting CC="ccache gcc" seems to confuse cibuildwheel into running ccache -pthread ... when the time for linking comes. is this a known limitation or am i doing it wrong? see https://github.com/harfbuzz/uharfbuzz/actions/runs/3838010513/jobs/6533968392#step:5:322

GitHub
Try and speed up Linux builds and reduce wheel size Β· harfbuzz/uhar...

A HarfBuzz Python binding. Contribute to harfbuzz/uharfbuzz development by creating an account on GitHub.

mystic leaf
#

@drifting dagger Might be nice to get a patch release out before the emscripten support is finished? The build backend fix would be nice to ship, pip 23.1 is nice too. No huge rush, but before PyCon is always a nice target. πŸ™‚

drifting dagger
#

Good idea! I'm quite busy at work this week but I reckon I can get a release out this evening. Thanks for sorting that build backend bug.

drifting dagger
#

@mystic leaf just sitting down to get the release out now. Is it worth getting https://github.com/pypa/cibuildwheel/pull/1476 in do you think? It's quite a lot of changes, but they look to be nearly all type changes so pretty low-risk?

GitHub
chore: ruff and typing updates by henryiii Β· Pull Request #1476 Β· p...

This adds a couple of Ruff checks, and updates typing. The deprecated typing generic aliases are replaced by proper collections.abc counterparts, checked by an added Ruff check. And list/set/dict h...

mystic leaf
#

Good question. It's low risk. Assuming CI passes, I'd be fine if you included it. But I don't think it's necessary to include, it's not going to affect end users, only readers.

drifting dagger
#

I dropped a comment on there, it looks totally fine to me but I'm a bit confused by the use of collections.abc

drifting dagger
#

v2.12.2 released!

drifting dagger
worn blaze
#

maybe link this from cibuildwheel docs

mystic leaf
upbeat ravine
#

is it a good hm or a bad hm πŸ˜„

mystic leaf
#

More of an "that's intersting" hm. πŸ™‚

mystic leaf
#

Not sure how forks are handled, etc. But still nice to see. (Actually, that's not including forks)

upbeat ravine
mystic leaf
#

Ahh, it was selected by the advanced screen, so thought that meant it was the default. 1.4K then, thanks!

woeful spindle
#

Hey @mystic leaf , I'd be curious if you could elaborate more about your admonition in the cibuildwheel docs about distribution builds for pre-release Pythons:

https://cibuildwheel.readthedocs.io/en/stable/options/#prerelease-pythons

This option is provided for testing purposes only. It is not recommended to distribute wheels built when CIBW_PRERELEASE_PYTHONS is set, such as uploading to PyPI. Please do not upload these wheels to PyPI, as they are not guaranteed to work with the final Python release. Once Python is ABI stable and enters the release candidate phase, that version of Python will become available without this flag.

A number of the Python core devs (Brett, Hugo, etc) do recommend it and find it quite useful, at least for things low in the dependency stack, to make testing with new Python versions a lot easier. However, they were wondering if there are specific issues or problems that they haven't considered/experienced but you had, given the depth of your exposure to this area, and wanted to know more about your reasoning here. I seem to vaguely recall there might have been a few issues that happened for 3.11 due to this, but can't remember any specifics myself. Would love to share your insights with them!

drifting dagger
#

I can't remember who wrote this text, I think we went through a few iterations with it together! The reason we have a warning here is that the wheels that result from this are tagged like they're compatible with the final release of cpython. However, we don't get any ABI stability guarantee from CPython until the release-candidate releases. So if cpython were to change ABI during the beta phase, wheels on PyPI would look compatible but break with the later releases.

#

It occurs to me that if those beta-phase wheels were tagged per-beta this wouldn't be a concern. And it would be quite nice to have prerelease numpy wheels as lots of packages do depend on numpy for their builds.

#

@mystic leaf might have more to add, being closer to the scientific community

mystic leaf
#

manylinux has roughly the same warning. One key difference is a wheel built with an ABI difference will likely segfault, compared to a Python wheel that will produce a readable error. And the first 3.x binary is very important for NumPy, which will forever use that wheel to build all 3.12 wheels in the future (okay, patch releases could possibly be moved to, but never a minor version. And even going up a patch version has to be extensively tested in oldest-supported-numpy. So NumPy is likely the last possible (though I'm with some of the NumPy team this week, so I could ask to see what they think).

I think we need a guarantee that binary compatibility will be preserved before we can recommend building and uploading support for Python-beta wheels. Or a tag to indicate that wheels were made with a beta (<4) Python. If a project tests cross-beta release compatibility (that is, downloads the wheels again and tests them against the new betas) and immediately deletes them if there's an issue, it's probably fine. But then if you are doing that you probably know what you are doing and don't need advice.

It also takes some time for projects to test, so for even the projects that want to upload beta wheels, I'd probably at the minimum wait till beta 2. I think there's a ton of movement right before beta 1, so I'd not really consider relying on beta 1's stability to be safe.

drifting dagger
#

@mystic leaf is the issue in #1507 still test_dependency_constraints_file? I can run that test locally, happy to debug if you like?

mystic leaf
#

Sure, I'm at the scientific-python dev summit, which means I'm going to be busy working on something else soon. My latest attempt is to just skip 3.6 and update the pins to modern enough versions to support 3.12.

drifting dagger
#

np, i'll have a tinker with it

mystic leaf
#

The seed packages are old for some reason, I think. I'm suspisious of our limiting virtualenv to a version before a fix went in for 3.12.

drifting dagger
#

well, it passes with pip pinned to 23.1.2

#

guessing that's just the first pip version that supported 3.12

#

that's the latest version. but i don't mind, the latest won't match the test-pinned version for long

#

just pushed it, we'll see

mystic leaf
#

Looks like it's going to pass. πŸ™‚

mystic leaf
#

Passed! (after restarting Win Travis a few times)

drifting dagger
#

Cool πŸ‘Œ I'm out today until the evening but will get a release out some time over the weekend.

#

Ive seen a couple references to what the steering council / Brett said about PyPI uploads- anyone have a link for that?

mystic leaf
#

The PyCon videos are not up yet

woeful spindle
#

Thanks @drifting dagger and @mystic leaf ! I'll pass that along. The impression I got from the core team/RMs is that there is intended to be an ABI stability guarantee starting with beta 1 rather than rc1, and at least in the recent releases, as far as people can remember that hasn't been actively broken (but you may be aware of some). Perhaps that could be expressly formalized and documented? I'll see what people say.

mystic leaf
#

If it’s up for debate, I’d vote for beta 2. There’s a push to get stuff in by beta 1 & even <24 hour reports aren’t enough to keep issues out of beta 1 (minor one not ABI related for the recent example in pybind11).

woeful spindle
#

In any case, we can continue the discussion over on https://github.com/pypa/cibuildwheel/issues/1505 and I'll direct people there, since Ned was part of the same conversation that prompted me to ask you here, and posted that in direct response.

mystic leaf
#

FYI, pytest (edit: not in all cases; the one I was seeing was caused by a plugin) is broken with beta 1, the PR fixing it is blocked waiting on beta 2. (https://github.com/pytest-dev/pytest/pull/10894) It was working with the last alpha before the beta, but the big push for beta 1 breaks things. I'd be pretty worried about the possibility of being locked in a corner if there was a requirement of no more ABI changes at beta 1. (Also, last I heard NumPy was segfaulting on beta 1)

drifting dagger
#

lucky for some, cibuildwheel 2.13.0 is out!

mystic leaf
#

I've resisted moving vX tags since cibuildwheel adds and removes platforms in minor releases, but what do you think about a moving vX.Y tag to reduce dependabot chatter on patch releases?

#

Dependabot won't update to a different number of .'s since April 2022, so it would be entirely opt-in.

drifting dagger
#

Sounds like a good idea to me! Do you know if there's a way to automate via Github actions?

#

I'd still document the fully-pinned way, I think that repeatable builds are great for many reasons

mystic leaf
#

I haven't done it before. How do you usually release?

drifting dagger
#

No worries, I can experiment. I was thinking that a Github action workflow on release:created might do the trick. I think I might have seen something similar in GitHub's own action repos.

drifting dagger
vivid flax
#

does cibuildwheel have automation to pick up the new Python releases (including 3.12 beta 2)? did I interpret the workflow correctly that it will next run on Monday?
https://discuss.python.org/t/python-3-11-4-3-10-12-3-9-17-3-8-17-3-7-17-and-3-12-0-beta-2-are-now-available/27477

Discussions on Python.org
Python 3.11.4, 3.10.12, 3.9.17, 3.8.17, 3.7.17, and 3.12.0 beta 2 a...

Greetings! Time for another combined release of six separate versions of Python! Before you scroll away to the download links Please test the 3.12 beta! Downloading it and trying it out helps us a lot in ensuring Python 3.12.0 will be as polished as possible. We welcome 3.10 to the prestigious club of security-only releases. It’s officially a...

drifting dagger
#

yes, version bumps happen on mondays. but I'll kick one off now since I think a lot of people will be waiting for 3.12.0b2

mystic leaf
#

(3.12.0b2 works without extra warnings with the latest pytest, might be part of the interest)

whole lagoon
dapper quartz
mystic leaf
#

We have a Tools plenary update (2:45 talk) in SciPy. πŸ™‚ Let me know if there's anything specific anyone would like included. I can share the slides once I start them. πŸ™‚

drifting dagger
#

thanks! πŸ™‚

mystic leaf
drifting dagger
#

Looks good @mystic leaf ! I can't think of anything to add πŸ™‚

mystic leaf
#

I just gave it, so that’s good. πŸ™‚

long nacelle
#

Would it be possible to cut a new cibuildwheel release with 3.12b4 support? That's expected to be the last beta, and came out earlier this week

long nacelle
mystic leaf
#

We are around, I'm currently at SciPy though so not following all the time. But you can see msgs here from today and yesterday. And totally okay to be pinged. πŸ™‚

long nacelle
#

fair enough, next time I'll ping πŸ™‚

#

I'm used to Python Discord levels of active, not PyPA Discord levels of active, hehe

mystic leaf
#

Ahaha, yes. πŸ™‚

mystic leaf
drifting dagger
#

That's a great improvement, as I understand it!

long nacelle
#

thanks for the quick turnaround on the 3.12 beta 4 support!

woeful spindle
long nacelle
#

It's special in that it's the last chance to request an ABI change, so it's important to test with from that PoV

#

More important than testing with any other beta, just because it's that last chance.

boreal wagon
mystic leaf
boreal wagon
#

interesting thanks! yeah this broke our build pipeline today when we upgraded to the latest version of psycopg

mystic leaf
#

I've attached relevant info to the issue.

#

Auditwheel 5 stopped embedding it, FWIU

reef igloo
#

I'm not sure if this should require a PEP, but LSB-compliance is probably not a good requirement for manylinux going forward. libcrypt.so.1 is part of that, and absent (at least by default) on most distros now. some real world python impact of this: https://github.com/indygreg/python-build-standalone/issues/173

#

Suffice to say, distros have collectively decided LSB-compliance doesn't matter.

woeful spindle
# reef igloo I'm not sure if this should require a PEP, but LSB-compliance is probably not a ...

See also https://discuss.python.org/t/29455 for some recent discussion on that

Discussions on Python.org
Is it safe to assume that manylinux1 and Python 3.12 will never be ...

Hello. In Fedora, we have a soft dependency of pip on libcrypt.so.1 with the following comment: # Some manylinux1 wheels need libcrypt.so.1. # Manylinux1, a common (as of 2019) platform tag for binary wheels, relies # on a glibc version that included ancient crypto functions, which were # moved to libxcrypt and then removed in: # https://fedora...

reef igloo
bleak flume
#

Is there any CIBW_BUILD_ISOLATION=false configuration that can be done for cibuildwheel? (equivalent to python -m build --no-isolation and pip wheel --no-deps --no-build-isolation) (context: testing, when we install the working versions of build requirements from the source directory instead of fetching from PyPI).

drifting dagger
#

You can set PIP_NO_BUILD_ISOLATION=1 in the environment, maybe there's a build equivalent also

bleak flume
#

Hi @drifting dagger thank you very much for the reply.

I found PIP_NO_BUILD_ISOLATION tricky to use (in https://github.com/PyO3/setuptools-rust/pull/352 it took me a long time to figure out how to make it work and solve the errors).

The reason is that, if when that env var is set, every call to pip install (e.g. the ones I make in CIBW_BEFORE_BUILD to install the build dependencies) will also be subject to the "no isolation" rule.

That is a bit error prone. Depending on the version of pip, setuptools, wheel that you have installed in the container (which I think comes with a very old version), the command in CIBW_BEFORE_BUILD have to be editted in a particular way (in https://github.com/PyO3/setuptools-rust/pull/352, I had to split it into 2, one for setuptools and one for the others, otherwise I faced errors).

It would be better if CIBW_BEFORE_BUILD is not affected by PIP_NO_BUILD_ISOLATION (it gives less margins for surprise/errors).
I believe that the best experience would be a CIBW_BUILD_ISOLATION or CIBW_BUILD_CMD (as suggested by Henry in #442).
Would you be interested in this as a feature request?

maybe there's a build equivalent also
I don't think it does.

drifting dagger
#

@bleak flume it would probably be a good idea to have a discussion on the issue tracker, not everyone checks discord. From my perspective, I'm kinda +0 on such a feature - it would be great to allow more customisability, but it also opens up cibuildwheel to supporting many more use-cases that I'm not totally sure I'm interested in. My hunch is that the limited options here subtly push packagers to create more standards-compliant wheel builds, which benefits the community and makes it easier to support our users.

#

that said, perhaps some of those concerns could be alleviated by making clear in the docs that if you do this, you're taking the less trodden path and 'on your own'

bleak flume
#

Thanks @drifting dagger , I will open an issue

mystic leaf
#

(Though only larger runners, which aren't free)

mystic leaf
#

The top 8 PRs are fine to go in, IMO. 1630 might be refactorable slightly, but close enough if we want to get it in for a release soon.

mystic leaf
#

cibuildwheel's pyproject.toml config now shows up in many editors, like VSCode. πŸ™‚

whole lagoon
#

Asking here since there's no auditwheel-specific channel. Is it possible to "re-repair" a wheel from a set of libraries you have on your system? Wanted to ask this question before learning about the elf format. My current thought is that repair doesn't leave enough information intact to be able to re-run.

hazy sluice
#

patchelf does not

whole lagoon
#

Neat, is that documented somewhere or you have a link for some code I can look at?

hazy sluice
#

The basic strategy is to get all of the current values that we care about from the binary, generate what the patch segment would look like with those values, and then compare the last PT_LOAD segment against those generated bytes. If they match, it just drops the previous patch and writes a new one with new values.

#

The caveat is that if you're only changing soname for example, the patch segment also includes rpath, needed, etc. The values are just copied from their original positions in the binary

#

that all said, I'm not sure whether it works at the wheel level with auditwheel invoking this code in elffile.py

viral laurel
#

What's the best way to pass a file path in CIBW_CONFIG_SETTINGS? Can I use {package} in it?

#

seems like package is ignored

#

ok, needed some github variable nesting hackery: CIBW_CONFIG_SETTINGS: ${{ matrix.cibw_arch == 'ARM64' && format('setup-args="--cross-file={0}/.ci/cross_amd64_arm64.txt"', github.workspace) || ''}} πŸ™‚

drifting dagger
#

@mystic leaf this test is a thing of beauty! I added a feature and it automatically told me it was missing from the schema.

image.png
worn blaze
#

There was information from pypa mailing list "Thanks to an introduction by William Woodruff, I have had a few discussions with folks at GitHub about our GitHub Actions queue size limits. As a result of those discussions, the pypa organisation is now on a free Enterprise plan." So we may should include macos-latest-xlarge runner that is m1 runner.

drifting dagger
#

Oh yes, good idea!

opal zenith
# worn blaze There was information from pypa mailing list "Thanks to an introduction by Willi...

I just tested this in https://github.com/pypa/cibuildwheel/pull/1700
It either require some more config at the org level to access those runners or, given PyPA has a free enterprise plan, there's no available credits to spin-up such a runner.

GitHub
chore(CI): test on GHA macos-13-xlarge runner by mayeut Β· Pull Requ...

PyPA is now on an enterprise plan.
Let's use the new macos-13-xlarge runner in order to test on macOS arm64.

vivid flax
mystic leaf
mystic leaf
#

We have the 17th most common tool section in pyproject.toml, with 1303 projects on pypi containing a tool.cibuildwheel section (as of about a week ago or so). πŸ™‚

turbid horizon
#

So… what’re the first 16?

#

and how do we overtake them? firPlot

mystic leaf
# 
  0 tool.poetry: 45523
  1 tool.black: 23128
  2 tool.isort: 16874
  3 tool.pytest: 15144
  4 tool.setuptools: 11136
  5 tool.mypy: 10279
  6 tool.coverage: 8907
  7 tool.ruff: 8485
  8 tool.setuptools_scm: 6034
  9 tool.hatch: 4846
 10 tool.pylint: 3725
 11 tool.pyright: 2948
 12 tool.flit: 2826
 13 tool.flake8: 1833
 14 tool.pdm: 1458
 15 tool.tox: 1423
 16 tool.cibuildwheel: 1303
 17 tool.semantic_release: 1276
 18 tool.poetry-dynamic-versioning: 982
 19 tool.maturin: 848
...
 49 tool.scikit-build: 135
...
104 tool.meson-python: 24
105 tool.repo-review: 23

Probably should have started that from 1. But can't, not Pythonic enough. I've added a few more lines for projects I work on. πŸ™‚

drifting dagger
#

that's pretty amazing, given how relatively niche a tool cibuildwheel is!

spice oxide
#

Yeah, there’s so many pure Python libraries out there that only need python -m build, while many of the other list entries are relevant to all kinds of projects

upbeat ravine
drifting dagger
#

πŸŽ‰ πŸŽ‰ πŸŽ‰

#

that's good news

#

it's odd that they still call it 'M1' when most of the line is on M2/M3

vivid flax
#

maybe they do have M1 hardware? would be cheaper than M2/M3, but still M1 is a huge hop from Intel, and will be a great help especially for cibuildwheel!

drifting dagger
#

yeah, dropping cross-compilation and doing it natively is a big simplification for lots of projects

mystic leaf
upbeat ravine
#

(but it's already implemented so)

mystic leaf
#

Right now there are runners for both. But that likely won't always be the case, especially since this is just "macos-14".

drifting dagger
#

i'm assuming they'll keep the intel runners around for a few years (hoping!)

mystic leaf
#

I wonder if "macos-latest" will become macos-14 at some point!

upbeat ravine
#

yeah, that's what I was getting at, I assume they're not planning to update intel runners to something newer than macOS 13

mystic leaf
#

Ouch, no pipx on the new runners?

upbeat ravine
#

not on the arm64 variant

#

interestingly there is still an x86 variant, I guess it might be for self-hosted runners?

vivid flax
upbeat ravine
vivid flax
#

quick comparison of testing Pillow on M1 vs Intel

image.png
mystic leaf
#

I think that looks like a mistake, the title of the PR is enabling python 3 and pipx.

upbeat ravine
#

I phrased that wrongly tbh

#

this PR added Python and pipx only to x86 (I assume there were some difficulties getting it on arm64 at first?) and I guess later the condition wasn't removed

#

oh no

#

Python is still missing

#

according to the report anyway

mystic leaf
#

That would explain it.

keen coyote
upbeat ravine
#

typically you'd use setup-python I suppose but it's still sad

upbeat ravine
#

it's not present in macOS 13 and newer

#

and macOS 12 shipped with Python 2.7

#

until 12.3 anyway

mystic leaf
#

For the action, we use setup-python anyway, so we could install pipx into it. Would be just a little slower, but up to date at least.

#

Pipx takes 1 second to install (at least on M1), so not that bad, I suppose. A tiny bit more annoying for nox than us.

mystic leaf
#

2.16.5 out, GHA AS support& powershell fix. πŸŽ‰

mystic leaf
#

We are at 2.8k (all non-fork) files mentioning of CIBW_BUILD on GitHub, FYI. 2.7k mentions of pypa/cibuildwheel (322 of joerick/cibuildwheel). 10.5k files mention "cibuildwheel" in general.

#

I need to see if there's a way to map PyPI project names to popularity somehow (downloads or something). I'd like to look at that list of projects with tool.cibuildwheel sorted by some sort of popularity ranking. πŸ™‚

drifting dagger
#

πŸ™‚

#

sourcegraph's search seems to put popular repos towards the top

mystic leaf
#

Yes, I got a lot of cibuildwheel's current examples that way. Could try that again to update our list.

#

But the pypi project names is a different dataset, so might be more interesting'

worn blaze
#

@mystic leaf @drifting dagger I made third attempt of add to dealocate validation of macOS platform tag. https://github.com/matthew-brett/delocate/pull/198
As it will impact cibuildwheel user I will open PR to docs with more explanation (and to allow problem be more searchable)
But it may be worth if you take a look on PR before it will be merged (for example current state of PR is to automatically update platform tag in wheel name). Maybe you spot some bug in assumptions.

GitHub
Third atempt to implement validating platform tag by Czaki Β· Pull R...

This PR is replacement for #61 and #68. This time using macholib.
Did You are still interested in this feature?
Did the initial implementation look ok?
If yes, then I will add test.

drifting dagger
#

it's about time for a release I reckon! Gonna be quite a big release. I'd like to get a dependency update, #1698, and #1775 in before then

#

I think i'll wait until monday to see if the manylinux1 docker issue is resolved before then.

#

any other burning desires?

drifting dagger
#

v2.17 out!

mystic leaf
#

Yes, just saw it, 2 minutes ago. πŸ™‚

drifting dagger
mystic leaf
#

Instead it will your platform automatically
?

drifting dagger
#

thanks for your work on this one henry πŸ™

#

haha whoops

#

it will detect your platform.

#

fixed.

worn blaze
#

I was going through uv readme and spot:

It's safe to run multiple uv commands concurrently, even against the same virtual environment. uv's cache is designed to be thread-safe and append-only, and thus robust to multiple concurrent readers and writers. uv applies a file-based lock to the target virtual environment when installing, to avoid concurrent modifications across processes.

#

It provide hope to go back to test parallelization that we have tried in past and hit problem with cache collision

mystic leaf
#

I’ve been wanting to try an installer=uv option. I’ve added that to quite a few projects now (nox, build, check-SDist)

mystic leaf
#

GitHub seems to be doing a staggered rollout of macos-latest pointing at macos-14, which means Intel jobs are being switched to ARM (and Python 3.10 is the oldest supported Python on those images via setup-python). Will surprise a lot of cibuildwheel users. (And other Python users in general)

mystic leaf
drifting dagger
#

Yeah, good point! Fortunately we did specify a pinned version in our sample configs, so most cibuildwheel users won't be automatically migrated.

mystic leaf
#

Looks like 3.8 and 3.9 are being released for the ARM runner now.

vivid flax
mystic leaf
#

They are shipped as of two hours ago.

mystic leaf
mystic leaf
#

We need to start thinking about Python 3.13 and free-threaded builds! Will there be official binaries with free-threading for macOS? We need those to build wheels.

#

(beta 1 is out, if it's not common knowledge at this point πŸ˜‰ )

vivid flax
#

Beta 2 is planned for 2024-05-28

mystic leaf
#

Okay, that works. Gives us time to get the first beta in normally (and for a non-beta pip release). (Seems wheel might not support 3.13 yet?) Thanks!

vivid flax
mystic leaf
#

Free-threaded isn't the problem, we need binaries for free-threaded; AssertionError: would build wheel with unsupported tag ('cp313', 'cpwin32', 'win32') is the problem. πŸ™‚

mystic leaf
#

And the fix was that .venv/bin/python -m mkdocs doesn't work, it has to be .venv/bin/activate && python -m mkdocs) (I think this is a mkdocs-macros-plugins bug, but it was annoying to say the least!)

cosmic sable
#

That's pretty silly..

mystic leaf
#

It was a bug in our macro module, but rendering the error into the page is still bad. πŸ™‚

#

How do we want to support free-threaded Python? Custom identifier? Variable? Both?

#

cp313t-*? tp313-*? Something else?

mystic leaf
#

I'd like to cut a release by Monday, to get macOS free-threaded out. That will also include Pyodide wheels. I'd love to get uv in too https://github.com/pypa/cibuildwheel/pull/1856 but not sure if that will make it. Reviews welcome. πŸ˜‰

GitHub
feat: build[uv] by henryiii Β· Pull Request #1856 Β· pypa/cibuildwheel

This adds support for setting the build backend to build[uv], which will use the build backend with the uv installer option. Using this will also move all installs over to uv if possible. Python &l...

drifting dagger
#

congrats on the release @mystic leaf ! that's a big one

worn blaze
mystic leaf
#

We should get a release out with 3.13b4. Especially since it's supposed to be the ABI stable release. I can do tomorrow unless @drifting dagger wants to.

drifting dagger
#

I'm just boarding a plane to France so I've run out of time to do the RC1 release today. If you wanted to do the release today @mystic leaf that would be great ! Otherwise I should get some time tomorrow

mystic leaf
#

Starting it now!

drifting dagger
#

Thanks for getting that release out Henry!

safe skiff
#

I'm unsure what to do about 313t for building wheels. Do I run cibuildwheel twice, once with CIBW_FREE_THREADED_SUPPORT=true, and once false?

mystic leaf
#

No, it just enables the extra build. You can even set it in your pyproject.toml as static config, which is what I would do.

safe skiff
#

Setting it to true means one run of cibuildwheel will produce two wheels?

#

hmm, seems not.

vivid flax
safe skiff
#

mentally diffs vastly different actions :)

safe skiff
mystic leaf
#

Where’s the config? On my phone and hard to track down from here

safe skiff
mystic leaf
#

Yes, that’s what I thought, you are selecting the specific build identifier. You’ll need to select the one with the t.

safe skiff
#

you mean CIBW_BUILD: cp313-*

mystic leaf
#

The environment variable adds the identifier since many people build * or cp*

#

Yes

safe skiff
#

would CIBW_BUILD: cp313*-* work?

mystic leaf
#

Yes. It’s a glob match against cibuildwheel’s known identifiers.

safe skiff
#

I have a feeling I am over-specifying options here, and could let cibuildwheel's matrix do more of the work

#

thanks, that worked!

mystic leaf
#

You can even have cibuildwheel generate the gha matrix. πŸ™‚

safe skiff
mystic leaf
#

https://iscinumpy.dev/post/cibuildwheel-2-10-0/

ISciNumPy.dev
🎑 cibuildwheel 2.10

cibuildwheel 2.10 is out, with some important additions. PEP 517 config
settings added, --only (which has an interesting use in GHA), and Cirrus CI
support (including our first Apple Silicon native runner!) are highlights. We
also support Python 3.11 now (as of 2.11.2, RC’s in older releases).
We’ve had some fantastic releases of cibuildwheel th...

safe skiff
#

so many different ways to mix-n-match tools that can make a matrix!

south oriole
#

Hi, there have been some updates to the Pyodide build procedure since the pyodide-build tool was unvendored from Pyodide's main repo recently. Would it be alright to open a PR directly (especially if the PR is not going to be too big)? I just wanted to ask because the Contributing guide asks to open an issue first. Otherwise, I'll gladly open an issue and discuss what I plan to implement.

mystic leaf
#

Sure, that’s fine, especially for maintenance type stuff

south oriole
#

In this case it adds a feature, but surely not a thousand-line patch ;)

drifting dagger
#

just putting together the next release...

drifting dagger
mystic leaf
drifting dagger
#

sadly yes. I think I'd like to get a bug fix release out with the revert back to tar pipes pretty soon

#

I actually don't understand what in mypyc's build process is shelling out to git - perhaps it related to their feedstock-style two repo setup, where the mypyc-wheels repo clones the mypy repo

#

so it might be that most users won't see it. even so, it feels very wrong that files in the container get UIDs to users that don't exist

outer cove
#

mypy's own build uses git to get it's current sha for dev builds

#

so this could affect anything using e.g. setuptools-scm or the like I presume?

drifting dagger
#

yeah good point, probably a decent number of people using setuptools-scm too

drifting dagger
#

@mystic leaf was just about to release but I saw #2008 with a fix to linux.py - is that something important that we should try to get in also?

mystic leaf
#

It would be nice, uv fix

drifting dagger
#

yeah, i've been reading up on it and it seems that we should get that in too

#

it's a shame we can't control the version of uv like we can the other tools we use

mystic leaf
#

We kind of do for Linux. πŸ™‚

drifting dagger
#

or maybe we can - we can pip install it i suppose

#

oh i see, it's pinned in the manylinux image

mystic leaf
#

Faster to let the user handle it. Especially when we use it to set up the environment that we are pip installing into.

drifting dagger
#

that's why we dont see the issue on main

#

yeah... chicken and egg problem to some extent

#

it's getting late here, but i'd love to get that bugfix release out - seeing as the uv version is fixed in the manylinux image, do you think it'd be a problem to release without #2008?

mystic leaf
#

It’s not too bad either way, I don’t mind releasing later for you if you would rather. It’s a bug that’ll affect somebody if they don’t use our pins for manylinux.

drifting dagger
#

hm yeah- and we do support just setting latest for the images don't we

mystic leaf
#

It should be good to merge as soon as the Linux job passes

drifting dagger
#

well if you get some time to do a release, that would be great, otherwise i'll try to do it in the morning. I'm going away to greece for a weeks holiday from tomorrow πŸ–οΈπŸ–οΈ so just trying to get things squared away before that !

#

here's the notes i drafted so far:

- πŸ› Fix a bug in the Linux build, where files copied to the container would have invalid ownership permissions (#2007)
- πŸ› Fix a bug on Windows where cibuildwheel would call upon `uv` to install dependencies for versions of CPython that it does not support (#2005)
mystic leaf
#

Make sure you pet a cat for me! πŸ™‚ I do miss how easy it was to travel while living in Europe.

#

I’ve merged that PR, will release when at a computer in a bit

mystic leaf
#

Released

mystic leaf
#

3.13.0rc3 out: https://discuss.python.org/t/python-3-12-7-and-3-13-0rc3-released/66306

Discussions on Python.org
Python 3.12.7 and 3.13.0rc3 released

This is not the release you’re looking for… (unless you’re looking for 3.12.7.) Because no plan survives contact with reality, instead of the actual Python 3.13.0 release we have a new Python 3.13 release candidate today. Python 3.13.0rc3 rolls back the incremental cyclic garbage collector (GC), which was added in one of the alpha releases. The...

#

We should get a release with this as soon as reasonably possible, there's a (private) ABI change due to the removal of the incremental GC. It doesn't affect users, but can affect profilers producing warnings. And can affect a few very specific users that embed headers.

mystic leaf
#

Okay, I think we are ready for a patch release? Small new feature that's opt in only (arm v7 musllinux) @drifting dagger?

#

Podman fix, 3.13 classifier, and of course, beta 3 are the main things otherwise.

drifting dagger
#

Yeah patch seems fine to me

mystic leaf
#

Are you doing the release, or would you like me to?

drifting dagger
#

i'm just catching up on my notifications, but i can do one this evening

drifting dagger
#

just putting it together now. Thanks for getting the PRs in shape!

drifting dagger
#

the updated publish workflow worked too πŸ™‚

drifting dagger
mystic leaf
#

Would it make sense to support dependency groups in cibuildwheel, just like we support extras now?

drifting dagger
#

i guess it does somewhat depend if pip end up reusing the extras-style syntax for them. Then they'd just work through the existing CIBW_TEST_EXTRAS option. But, that seems a bit unlikely to me

mystic leaf
#

I think it's completely valid to have both [test] and a test dependency group. And dependency groups won't require installing the package. So it's very likely to be some new flag, I think.

#

I think uv is calling it --groups

#

And yes, nothing supports them yet. But I'd assume uv will very, very soon, and pip in the future, so worth starting to think about it.

kind cedar
keen coyote
#

because some people might want to build your package on their special hardware that you don't ship binaries for

#

like iOS/Android, which don't have wheel tags and build support on CIBW

kind cedar
#

But it is not mandatory if say I am only targeting linux

keen coyote
#

it's not mandatory, no, but sdists are not that hard to make, they are basically your project's source packaged with some metadata

#

I don't see any reason to skip sdists

kind cedar
keen coyote
#

yes, looks fine for sdists only

kind cedar
#

oh know I want something that builds it

pip install builds with cmake
How can I deploy manylinux wheels to pypi?

keen coyote
#

in your case there will be just a bit more to do in terms of building wheels, but the publishing stuff is the same no matter what

kind cedar
#

Thank you all worked like a charm

mystic leaf
#

We should get a release out with dep groups and raspberry pi support. I'd still like https://github.com/pypa/cibuildwheel/pull/2064, but that's a developer change and could either be added before release, after release, or next year.

worn blaze
mystic leaf
#

And if you are targetting linux, there are linuxs that aren't wheel supported (like ClearLinux)

worn blaze
#

@mystic leaf @drifting dagger What did you think about PR to delocate to detect binary dependencies installed from brew and crash the process in such case, and then enable it by default?

mystic leaf
#

Doesn't that already happen if you link in a binary? And if it's for CLI tools, normally those work just fine (like cmake and such) - it might be that pkg-config is a special case here.

worn blaze
#

No. Normally the delocate just copy the dependecies from brew into wheel

mystic leaf
#

But I thought it checks for the macOS target version and arch?

drifting dagger
#

I'd support a change to delocate to check bundled deps against MACOSX_DEPLOYMENT_TARGET and archs. Although I thought that, at least it already corrects the produced wheel tag

drifting dagger
mystic leaf
#

You'd not be able to catch this one, I think, as I belive the problem is that the wrong Python is being used (we get the Intel one on ARM for 3.8)

worn blaze
mystic leaf
#

Are we ready for release?

drifting dagger
#

Sure looks like it! I'm a bit busy with work this week but could probably got one out on Friday

#

If you have time earlier than that henryiii and want to release then feel free to

mystic leaf
#

I might be able to do it later today. Otherwise you will likely get to it first.

south oriole
mystic leaf
#

I didn't manage to get a release out yesterday, so probably yes. πŸ™‚

mystic leaf
#

Cross posted here too for visibility:

Wild idea (probably), but what about allowing the version to be part of the platform? So --platform pyodide would be the default version, but --platform pyodide-0.27.0a2 would be allowed, too. This would tie the pyodide-specific setting to the pyodide platform only. But this would not allow you to require a specific version inside pyproject.toml, I guess. Thoughts?

south oriole
#

Responded on the PR

#

I also notice that since we use Python 3.12.7 in Pyodide 0.26.4, the Python version set in build-platforms.toml as 3.12.1 seems to get ignored and 3.12.7 gets set up everywhere. I'm not sure why that happens.

mystic leaf
#

We don't set up Python for pyodide, we just use it from the system. The Pyodide host should support any patch version?

south oriole
#

Yes, any version that supports pyodide-build's requirement (which is any version about 3.12) works. But in that case, python should probably be removed from there, isn't it? Since the Pyodide xbuildenv that pyodide-build downloads/installs using pyodide xbuildenv install sets up its own Python interpreter.

mystic leaf
#

Maybe it's there because it's in just because of the others having it? It also might have something to do with the typing elsewhere expecting a python version here.

#

Should enscripten version come from pyodide version?

#

And maybe node version?

south oriole
#

Let me have a look at this. I think there is a bit more to do for me here, so I would say that this PR shouldn't block the release, please go ahead :)

mystic leaf
#

Making this user settable somewhat changes the usefulness of this line in build-platforms

#

Not likley to release before tomorrow

south oriole
#

The Emscripten version should come from the Pyodide version, yes. The Node version can be anything >= 20. I think even 18 would work, but it's deprecated now.

#

The idea behind the PR is essentially that the cibuildwheel version has coupled the Pyodide version with it (for all the right reasons of stability), and I think users would like the one-liner convenience it has to build WASM wheels instead of having to install pyodide-build, install an xbuildenv, install Node.js, Emscripten, etc. So with it being an experimental platform, experiments with new Pyodide versions (which sometimes bring Emscripten ABI breaks) could be allowed with cibuildwheel too.

mystic leaf
#

Sure, I'm just saying this line in build-platforms may need trimming or removal.

#

The default for pyodide-version will likely move to defaults.toml

south oriole
#

Ah, I thought you were referring to the Pyodide xbuildenv version being user-settable (using CIBW_PYODIDE_VERSION), sorry!

mystic leaf
#

So it sounds like the only value left that's important in build-platforms.toml is node_version.

south oriole
#

The pyodide_build_version would be important, too, since it would be what would control if pyodide_version is compatible with it or not

mystic leaf
#

Isn't that in the constraints file, though?

south oriole
#

Ah yes, it is

mystic leaf
#

I think we might limit it when making the constraints file based on this value, so it might be worth keeping, it just also might be wrong if a user sets something different

south oriole
#

We could indeed drop all values. So we should be left with:

{ identifier = "cp312-pyodide_wasm32", pyodide_version = "0.26.4", node_version = "v20" },

but then it's not expected that anyone needs to test changes with a different Node version, so I'm a bit confused... Do we only need the identifier in build-platforms.toml, and the pyodide-build version from the constraints file would then pick the Pyodide version from here (unless overridden with a CIBW_PYODIDE_VERSION env var that's added + a --pyodide-version CLI flag that I need to add) and set up an xbuildenv, and the Emscripten version would in-turn come from the Pyodide version?

#

There's never going to be two Emscripten versions for one Pyodide version either. But two Pyodide versions can have the same Emscripten version.

mystic leaf
#

No CLI flag, I think it should be just pyproject.toml + env var. We only elevent a few things to CLI flags. The cli flags are also not available in the GitHub Action, while environment variables are.

south oriole
#

Yup, in pyproject.toml – oops

mystic leaf
#

I think that's ideal if it works. I suspect the python version is required in some other part that reads this file, but I think the patch part can/should be dropped.

#

(macOS doesn't have the patch version, for example)

#

pyodide_version could be dropped in favor of defaults.toml having it.

#

So { identifier = "cp312-pyodide_wasm32", version = "3.12", node_version = "v20" }, might be the ideal minimal version.

#

This probably won't allow new Python version pyodide versions to be tested.

south oriole
#

I see. So does that mean Python 3.13 with Pyodide 0.28 would break if someone wants to set 0.28 using CIBW_PYODIDE_VERSION? That wouldn't be helpful, I think.

mystic leaf
#

I believe so, as cibw wouldn't know about the 313 classifier for pyodide.

#

(Unless the 312 one just produced a 3.13 wheel anyway)

#

Ahh, that's also an intersting implication. If we have both 312 and 313 in the future, build-platforms.toml can have a different pyodide-version per Python version, while defaults.toml and an environment variable cannot.

south oriole
#

So "allow arbitrary Pyodide versions to be tested" wouldn't be truly arbitrary in that case, since people wanting to try out a new Pyodide 0.28 wouldn't be able to do so

south oriole
#

so the question is likely, "how can we be rigid enough yet still be flexible to allow testing?"

mystic leaf
#

PyPy does the same thing, but we provide all past versions anyway. So I think we'd be very likely to have 312 and 313 at the same time in the future.

#

Have you started adding this to defaults.toml and such? What about just leaving it environment variable only and considering it experimental for now, and maybe we can come up with something better for 3.0?

south oriole
#

Having both 3.12 and 3.13 would be a bit confusing for those who would start seeing two Pyodide versions being built for – after which they would set CIBW_BUILD to block the 312 identifier / Pyodide 0.27 from building and build only for Pyodide 3.13. I guess adding support for one identifier should be marked with dropping support for another, so only one Pyodide version gets built.

#

I don't wish to hurry you here :) but yes, "environment variable only" sounds good. I haven't started adding changes to defaults.toml yet, at dinner rn. Could we figure out a solution for the "Pyodide-new-version has come out, uses Python 3.Y but a cibuildwheel version that supports Pyodide-old-version can't build wheels for Pyodide-new-version via custom CIBW_PYODIDE_VERSION because it has the Python 3.X identifier and lacks the 3.Y identifier" problem?

mystic leaf
#

I think the solution is something we could work on for cibuildwheel 3. It' s a bit complex since it's also tied to the system Python, so currently you can't build for two versions at the same time, and you have to change the installed Python version to update to 3.13. But we can probably solve those (since any Python 3.X works, as long as X is correct, it doesn't need to be official installers).

#

I think we can probably just build whatever CIBW_PYODIDE_VERSION forces, even if doesn't match the identifier, for now. Is there a dev release or something to test it with, though? I'm sure the Python version shows up in a few places. Our tests won't pass, I expect, as we probably check the filename output, but that's fine

south oriole
#

Quite a tricky problem indeed – for now, yes, 0.27.0a2 is one of the alpha releases you can test it with. I converted the Pyodide CI job to a matrix that tests both the standard Pyodide version (upgraded from 0.26.1 to 0.26.4) and a custom Pyodide version via CIBW_PYODIDE_VERSION, and both jobs are passing there. This will work fully for 0.27 stable soon and for any more 0.27 alphas that we release (no Emscripten version or Python minor version bump in this release), but is going to fail with 0.28 where we will have upgraded to 3.13 by then, as we've managed to discuss above. I think it would invite quite a few bug reports, too – if people do end up using this environment variable, that is. And that sort of makes me feel I should close this PR, but I'm open to thoughts...

#

I also have https://github.com/pyodide/pyodide-actions/issues/12 in mind, which will drop a lot of the boilerplate that is present in most of the Pyodide/Emscripten CI jobs present in the wild. But people do enjoy using cibuildwheel – at least I do, quite a lot!

GitHub
A `setup-xbuildenv` composite action? Β· Issue #12 Β· pyodide/pyodide...

When writing a CI workflow for an out-of-tree build, one needs to: Download Emscripten (and cache it), Set up Python 3.12 and above (or those determined by pyodide-build's constraint), Set up N...

mystic leaf
#

I expect an environment variable as a somewhat sneaky backdoor for testing is okay - most users won't care about the exact version. And the other updates are good (we aren't regularly updating pins on this, it seems).

#

Though maybe it should be undocumented. Open to opinions. Longer term, we might be able to come up with a more elegant solution.

south oriole
#

Thanks – I was just going to ask about those. The PR is indeed conflating two things, so in the meantime I'll split up the pyodide/pyodide-build version bump in a new PR just now, that can go in without much trouble.

mystic leaf
#

It could also be versioned. CIBW_PYODIDE_FOR_312 or something like that.

#

Though I'd probably not add something like that just yet as we need to solve the host Python version once 3.13 enters Pyodide alphas.

south oriole
#

I agree. You've mentioned that the tests will fail if Pyodide 0.28 + Python 3.13 is targeted when Pyodide 0.27 + 3.12 as the identifier exists. Does that mean the testing of the WASM wheel through pytest --pyargs etc. that cibuildwheel builds, or cibuildwheel's own test suite? As in, if there is some behaviour that validates the built wheel's filename and checks for cp312 in the string, we could just disable it for Pyodide.

mystic leaf
#

I expect cibuildwheel's test suite will fail if CIBW_PYODIDE_VERSION is set to a version with 3.13 due to name checks.

#

We can just try it out when there's a 3.13 alpha, though I'm also fine to actually add support once there's a 3.13 alpha. πŸ™‚

south oriole
#

I'll explore the test suite more in a bit when I can. Disabling cibuildwheel's test suite for Pyodide doesn't sound like too much trouble for a flag that's experimental. As long as CIBW_TEST_COMMAND_PYODIDE does not fail for users, we should be good to go, then.

mystic leaf
#

We can just not run the test suite with CIBW_PYODIDE_VERSION set to a version that has 3.13 in it for now πŸ™‚

#

(Especially since there isn't one yet)

south oriole
#

That should work!

south oriole
mystic leaf
#

Released 2.22.0! In a day or two we can make the 2.x branch, and start merging 3.0 PRs. Waiting a little just in case we need quick fixes is probably good idea, though. πŸ™‚

mystic leaf
#

Manylinux inspector needs to support the new manylinux. And it would be really useful if it would show the gcc version

mystic leaf
#

Found the repo so added issues there.

upbeat bramble
mystic leaf
upbeat bramble
#

ah, I see

mystic leaf
#

It's there now, thanks @drifting dagger! Should we make a patch release now too?

kind cedar
#

Quick question about cibuildwheel

I have this workflow

That builds my package correctly for python 3.10 3.11 and 3.12
How ever when it uploads I say that I have the binary of the 3.10 everywhere and I cannot import my built library on 3.11 3.12

What am I doing wrong

GitHub
jaxDecomp/.github/workflows/github-deploy.yml at main Β· Differentia...

JAX bindings for the NVIDIA cuDecomp library. Contribute to DifferentiableUniverseInitiative/jaxDecomp development by creating an account on GitHub.

mystic leaf
#

You've set wheel.py-api = "py3", which means you build one wheel for all versions of Python. Guessing from above that's not correct?

#

You use that for wheels that don't touch CPython's API, often wrappers for CLI applications, like cmake, ninja, etc.

kind cedar
#

Thank you πŸ™
Worked great

outer hedge
#

I have a question about missing symbols in a cibuildwheel setup using scikit-build. I'm building project A, which depends on project B. In the CIBW_BEFORE_BUILD, I'm compiling and installing project B in the cibuildwheel container. I then proceed to build project A, which links in project B.
Here's the problem. When I install the wheel built from this project, a runtime error for an undefined symbol (htole32 from glibc endian.h) is thrown. As far as I can tell, this is in glibc, shouldn't this be resolved automatically?
htole32 is used in project B, and when I inspect the wheel the symbol is undefined. Which is what I would expect if the symbol is assumed to be present at runtime.

Is there a way to either (1) include the symbol somehow or (2) fix the wheel building setup to correctly bundle the dependencies to avoid the missing symbol?

The build configuration with cibuildwheel can be found here: https://github.com/aestream/event-camera-drivers/blob/main/.github/workflows/build.yml#L38
The dependency (project B) is built here: https://github.com/aestream/event-camera-drivers/blob/main/.github/workflows/install_libcaer.sh

GitHub
event-camera-drivers/.github/workflows/install_libcaer.sh at main Β·...

Event camera drivers. Contribute to aestream/event-camera-drivers development by creating an account on GitHub.

GitHub
event-camera-drivers/.github/workflows/build.yml at main Β· aestream...

Event camera drivers. Contribute to aestream/event-camera-drivers development by creating an account on GitHub.

outer hedge
upbeat ravine
worn blaze
#

I have reported this spam issues in our repository, but only person with admin permission could delete it or lock user.
If we wait few hours the github admin should remove it

worn blaze
#

It looks lik github admin cleaned everything

quiet karma
#

For a rust project, should I use maturin generated ci or cibuildwheel?

#

(first time writing an extension module so I have no idea about the proper workflow)

cosmic sable
#

We use Maturin for uv / ruff β€” I am not sure of the trade-offs but they could be a good example if you want to go that route.

mystic leaf
#

Cibuildwheel will be slower. We do a lot of set up to make sure that clibs work that you usually don’t need if you’re using rust.

#

But if you need that, then you can use it

quiet karma
#

I tried my hand at maturin ci and failed miserably, so now I'm trying cibuildwheel and it works!

#

I don't mind it being slow since it'll only run for a release anyway

# 
14 wheels produced in 10 minutes:
  rnzb-0.1.0-cp310-cp310-manylinux_2_28_x86_64.whl            970 kB
  rnzb-0.1.0-cp310-cp310-musllinux_1_2_x86_64.whl           1,028 kB
  rnzb-0.1.0-cp311-cp311-manylinux_2_28_x86_64.whl            970 kB
  rnzb-0.1.0-cp311-cp311-musllinux_1_2_x86_64.whl           1,028 kB
  rnzb-0.1.0-cp312-cp312-manylinux_2_28_x86_64.whl            968 kB
  rnzb-0.1.0-cp312-cp312-musllinux_1_2_x86_64.whl           1,027 kB
  rnzb-0.1.0-cp313-cp313-manylinux_2_28_x86_64.whl            967 kB
  rnzb-0.1.0-cp313-cp313-musllinux_1_2_x86_64.whl           1,026 kB
  rnzb-0.1.0-cp313-cp313t-manylinux_2_28_x86_64.whl           966 kB
  rnzb-0.1.0-cp313-cp313t-musllinux_1_2_x86_64.whl          1,025 kB
  rnzb-0.1.0-cp39-cp39-manylinux_2_28_x86_64.whl              971 kB
  rnzb-0.1.0-cp39-cp39-musllinux_1_2_x86_64.whl             1,029 kB
  rnzb-0.1.0-pp310-pypy310_pp73-manylinux_2_28_x86_64.whl     971 kB
  rnzb-0.1.0-pp39-pypy39_pp73-manylinux_2_28_x86_64.whl       971 kB
#

it did not build pypy aarch64

# 
jobs:
  build_wheels:
    name: Build wheels on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        # macos-13 is an intel runner, macos-14 is apple silicon
        os: [ubuntu-latest, windows-latest, macos-13, macos-14]

    steps:
      - uses: actions/checkout@v4

      - name: Build wheels
        uses: pypa/cibuildwheel@v2.22.0
        env:
          CIBW_BEFORE_ALL_LINUX: curl -sSf https://sh.rustup.rs | sh -s -- -y
          CIBW_BEFORE_ALL_WINDOWS: rustup target add i686-pc-windows-msvc
          CIBW_ENVIRONMENT_LINUX: "PATH=$HOME/.cargo/bin:$PATH"
          MACOSX_DEPLOYMENT_TARGET: "11.0"
          CIBW_ENABLE: "pypy cpython-freethreading"
          CIBW_BUILD_FRONTEND: "build"
          CIBW_MANYLINUX_X86_64_IMAGE: "manylinux_2_28"
          CIBW_MANYLINUX_PYPY_X86_64_IMAGE: "manylinux_2_28"
          CIBW_MANYLINUX_AARCH64_IMAGE: "manylinux_2_28"
          CIBW_MANYLINUX_PPC64LE_IMAGE: "manylinux_2_28"
          CIBW_MANYLINUX_S390X_IMAGE: "manylinux_2_28"
          CIBW_MANYLINUX_PYPY_AARCH64_IMAGE: "manylinux_2_28"
          CIBW_SKIP: "*-manylinux_i686 *-musllinux_i686"

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

I don't think I've accidentally excluded it?

#

There's no tool.cibuildwheel in my pyproject either, so that's all the configuration you see

mystic leaf
#

You aren't getting any wheels from emulated archs because you haven't set up emulation and you didn't explicitly ask for them. CIBW_ARCHS: auto is the default, which means native only (usually 64 bit native, though it includes 32 bit on Windows 64)

#

I'd use pyproject.toml so you don't have to have it tied so closly to GHA, makes it easier to run locally, for example. I'd also use build[uv], which will shave a bit of the overhead off (you'll want a setup-uv action before it in that case, too). I'd highly recommend using the new ubuntu-24.04-arm images instead of emulating arm, it's simpler and 10x faster.

#

Emulation is where the difference really shows up between maturin's action and cibuildwheel. Maturin can cross-compile, so it's much faster, though you can't test the wheels. By the way, I'd also add testing if you can.

quiet karma
#

I'll add ubuntu arm to the matrix and switch to build[uv] when I get back to it

#

Had no idea GitHub added thatπŸ˜„

mystic leaf
#

cibuildwheel<3 doesn't run the tests from the repo. I believe we are actually changing that for version 3, as it wasn't that helpful in solving what it was supposed to solve.

#

So you need to use {project}/... or something similar to run.

quiet karma
#

I used pytest {project}/tests -vv but maybe because my tests use relative path (... = Path("tests/nzb")) something went wrong? I might try __file__ next

mystic leaf
#

Looks like you are trying to import from the tests directory. That won't work. I think you can just add tool.pytest.ini-options.pythonpath = ["tests"] (IIRC) but better would be to nest it one layer down and then use "tests/utils" or whatever as the path, I think. (from memory, so might have gotten the exact option wrong)

#

Oh, wait, maybe not, rnzb != nzbs, I didn't notice those were so close

#

Yes, you are correct. Path("tests/nzbs") is wrong, as that's the current working directory, not the directory the file is in.

#

DIR = Path(__file__).parent.resolve(), DIR / "tests/nzbs" is the idiom.

#

(.resolve() only needed for older Pythons)

quiet karma
#

ah okay, good to know it's a simple fix

mystic leaf
#

You can just run pytest from a different directory (like one up) to test this quickly

#

(I personally never cd into the tests dir to run tests, but just run pytest from the main folder and have tool.pytest.ini-options.testpaths = ["tests"] set)

quiet karma
#

okay I'll add that

#

Thanks a lot 😁

mystic leaf
quiet karma
#

Nice, I'll definitely give it a read

mystic leaf
#

Oops, ini-options -> ini_options above

quiet karma
#

I managed to successfully publish my first extension module with compiled wheels to PyPI! Just wanted to thank the maintainers of cibuildwheel, pyo3, and maturin for making whole process surprisingly easy for a newbie blobthx

quiet karma
#

I'm not sure whether my issue is uv related or cibuildwheel related, so I'm reposting this from the astral server:

#

Anyway to mark that a dependency must only he installed on non free threaded environment?

# 
[dependency-groups]
test = [
    "nzb>=0.4.0 ; python_full_version >= '3.10' and implementation_name == 'cpython'",
    "pytest>=8.3.4",
]

I have this in my dependency-groups, where nzb depends on msgspec which does does not publish free threaded or pypy wheels and only a single test in my code depends on this

#

The test code also has a skipif:

@pytest.mark.skipif(
    sys.version_info < (3, 10) or sys.implementation.name != "cpython", reason="requires CPython 3.10 or higher"
)
def test() -> None:
    import nzb
    # do stuff with nzb
#

Since I do publish pypy and free threaded wheels (well before adding the above test), I want to simply skip installing/testing that in incompatible environments

#

I'm using cibuildwheel to build and test the resulting wheel where the build succeeds but the test fails on pypy/freethreaded because cibuildwheel calls uv pip install "nzb>=0.4.0 ; python_full_version >= '3.10' and implementation_name == 'cpython'"which in turn fails because it can't build msgspec

#

I think the easiest solution for me is to skip all the tests on pypy/freethreaded but I wouldn't wanna do that unless there's no other way

#

I guess another thing I can do is add a python version to <3.13 to nzb

mystic leaf
#

I believe this is an issue with a lack of environment markers for free-threaded builds. IIRC someone (could have even been me, don't remember) requested one, but it didn't make it.

#

I think this is it: https://discuss.python.org/t/environment-marker-for-free-threading/60007

Discussions on Python.org
Environment marker for free-threading

Is there a PEP 508 environment marker for free threading? Unsurprisingly, my packages need newer versions of build dependencies (some prereleases) when building for free threading. I haven’t been able to find an environment marker to be able to specify the different dependencies under the right conditions. Related, I suppose: I don’t see any me...

#

Feel free to comment there with your use case. In cibuildwheel, you can of course define an override and split the test group into two, with the override taking a different group.

[dependency-groups]
test = [
    { include-groups = "test-freethreaded" }
]
test-freethreaded = [
    "nzb>=0.4.0 ; python_full_version >= '3.10' and implementation_name == 'cpython'",
    "pytest>=8.3.4",
]

[tool.cibuildwheel]
enable = ["cpython-freethreading", "pypy"]
test-groups = ["test"]

[[tool.cibuildwheel.overrides]]
select = ["c*t-*"]
test-groups = ["test-freethreaded"]
quiet karma
#

That handles my case, thank you. And yep, a marker would have helped πŸ˜„

boreal wagon
#

does project.requires-python not influence what versions get built? I have requires-python = ">=3.9" but it's still trying to build 3.8

mystic leaf
#

It’s supposed to

#

Do you have any other configuration that might be affecting it?

boreal wagon
#

nevermind sorry, there are two jobs and one of them is misconfigured

mystic leaf
worn blaze
#

@mystic leaf @drifting dagger Did you understand the point of https://github.com/pypa/cibuildwheel/issues/2342 ?
I do not see big value for support it.
It smeel for me that we land on some list "should be ported" and person opening Issue do not provide the proper motivation.

The CirrusCI provides FreeBSD runners

mystic leaf
#

I expect that's exactly it.

worn blaze
#

Did you have suggestion how we should response?

worn blaze
drifting dagger
#

@south oriole did you start working on the python-build-standalone integration for pyodide yet? I have a script here that might serve as a pretty good starting point, happy to tidy it up if you haven't started that work yet

south oriole
drifting dagger
#

ah, great timing

#

yes i just pushed the thing i've been working on

south oriole
#

ah nice!

drifting dagger
#

python-build-standalone is such a convenient project... cibuildwheel would be a lot simpler if we could just use that for everything!

#

but yes i'm just in the process of plugging it into the pyodide cibw platform

south oriole
#

is that the one they use with uvx python? it's really innovative, for sure!

drifting dagger
#

yep

south oriole
#

BTW, I faced some troubles recently when I tried to use uvx cibuildwheel with Pyodide builds. I assume it was using python-build-standalone as I've configured uv to fetch interpreters from it.

drifting dagger
south oriole
#

ah, superb!

drifting dagger
south oriole
#

it is fetched dynamically from that JSON file, yes – we can grab it at runtime.

also, if you're keen, we can also hardcode the values of Pyodide and Pyodide's Python as a mapping – 0.26.x <-> 3.12.1, 0.27.x <-> 3.12.7, 0.28 <-> 3.13.1 and so on? that wouldn't be predictable, but these values can be updated at any time.

drifting dagger
#

ah, cool. i was thinking we'd fetch the python versions from pyodide-cross-build-environments.json at runtime - that way you can specify a CIBW_PYODIDE_VERSION for a new version of pyodide that was released after cibuildwheel - otherwise we'd be waiting for a cibuildwheel release before people can test new versions of pyodide

#

(also it's maybe less maintenence for us to keep that mapping external)

south oriole
#

ah, okay, that makes sense! I was concerned on the aspect whether people would like their wheel builds to work fully offline, but I think the "ci" in "cibuildwheel" means one can't really guarantee that πŸ˜…

drifting dagger
#

indeed - and we can never get away from requiring a connection to PyPI for packages, so it's no worse than that anyway. The only thing i wonder if whether github would ever rate-limit those "raw.githubusercontent.com" urls, but I've never seen it. cibuildwheel used to use them and never had an issue. And if you're using them in pyodide-build then it makes no difference πŸ™‚

south oriole
#

yes indeed. I'm sure the github platform health teams would be on it if there were to be an issue related to this. A lot of research datasets are stored on raw GitHub URLs, and IIRC they use cloudflare as a CDN for them, and therefore have heavy caching for them anyway. and if there's ever a problem, we can wrap them with https://statically.io/.

upbeat ravine
#

There used to be rawgit but that project was shut down

south oriole
#

yes! pyodide uses jsdelivr for its own package index. we've never had an issue with them and I think they were generous with OSS projects. :D

drifting dagger
#

I just hooked it up - actually, having coded it up, it looks like maybe we don't need to read pyodide-cross-build-environments.json, since the patch version doesn't matter, and the version of python is written into build-platforms.toml already. which is nice, saves a bit of complexity anyway

south oriole
drifting dagger
#

unfortunately, the pyodide venv command makes symlinks.... so this might be something of a dead end :/ i'll post on the PR

south oriole
#

oh I just did

drifting dagger
#

ah, yeah i see you're tracking this already in pyodide. Annoying bug, it seems that python-build-standalone is the only distribution that exhibits it

boreal wagon
mystic leaf
#

That just added an explicit ci run, it works fine, nothing was changed. (I’ve got a Windows ARM dev box that I’ve tested it on before, so it’s not too surprising) It’s being used already in packages like boost-histogram

#

The MSVC setup action doesn’t support native ARM, so make sure you don’t use that

viral laurel
twilit jetty
#

I am getting strange behavior building fortran using f2py on windows with scikit-build-core.

Directly running:

python -m build -v --wheel --config-setting=cmake.args=-GNinja

works great, but

CIBW_CONFIG_SETTINGS_WINDOWS="cmake.args=-GNinja" cibuildwheel.exe

throws errors while running ld

      C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/_thermal_comfort.dir/_thermal_comfortmodule.c.obj:_thermal_comfortmodule.c:(.text.unlikely+0x27): undefined reference to `__imp__Py_Dealloc'

      collect2.exe: error: ld returned 1 exit status
      ninja: build stopped: subcommand failed.

      *** CMake build failed
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for thermal-comfort
Failed to build thermal-comfort
ERROR: Failed to build one or more wheels
::endgroup::Building wheel...

There are dozens of the above undefined reference to ... errors

you can find the branch in question and dozens of gha run here: https://github.com/RUBclim/thermal-comfort/tree/windows-wheels

...it took me some time to find out that I had to specify -G Ninja. But that only brought me to the linking errors. Any idea very much appreciated!

mystic leaf
#

Do you have to require Ninja? It's the default on Unix platforms and it's much harder to setup on Windows. MSVC works out of the box but Ninja requires proper environment setup to correctly find MSVC compilers.

#

Above it looks like it's finding GCC instead of MSVC. CPython is built with... Ahh, you said Fortran.

#

We do run the fortran example in CI if gfortran is installed.

twilit jetty
#

without it, it does not find a fortran compiler

CMake Error at CMakeLists.txt:2 (project):
  No CMAKE_Fortran_COMPILER could be found.

If I set CMAKE_fortran_COMPILER it discovers gfortran, but then asks for an .sln file - probably some MSVC project file ?!

I never touched fortran on windows before or used the intel compiler, but people now want it on windows...

twilit jetty
#

it runs devenv <something> and that needs `.sln?

mystic leaf
#

In scikit-build-core. Do you have tests working on Windows and it's only in cibuildwheel that there's a problem?

#

I've gotten tests to work. Not sure I've set up working wheels with Fortran + Windows. I think some users have, though.

#

I think you are mixing msys and Windows CPython

twilit jetty
mystic leaf
#

No, I think it just skips the test in that case, I think it's not present on Windows.

twilit jetty
#

I just started looking into that to rule out msys!

mystic leaf
#

I've used what I think was an early version of that action, and my comment was that it took too long on Windows so it was disabled, but not that it didn't work. I'm going to try that.

#

(On the scikit-build-sample-projects repo)

twilit jetty
#

yeah 5 1/2 minutes setup time...

#

Mhm, got it to install, but it's not working...

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\a\thermal-comfort\thermal-comfort\venv\lib\site-packages\thermal_comfort\__init__.py", line 1, in <module>
    from thermal_comfort._thermal_comfort import thermal_comfort_mod
ImportError: DLL load failed while importing _thermal_comfort: The specified module could not be found.

 Directory of D:\a\thermal-comfort\thermal-comfort\venv\Lib\site-packages\thermal_comfort

04/28/2025  04:40 PM    <DIR>          .
04/28/2025  04:40 PM    <DIR>          ..
04/28/2025  04:40 PM            13,013 models.py
04/28/2025  04:40 PM                 0 py.typed
04/28/2025  04:40 PM            13,673 utils.py
04/28/2025  04:40 PM    <DIR>          _thermal_comfort
04/28/2025  04:40 PM            97,280 _thermal_comfort.pyd
04/28/2025  04:40 PM             1,869 __init__.py
04/28/2025  04:40 PM    <DIR>          __pycache__

No idea how it's supposed to look on windows, but I would expect a dll there like the .so on linux, no?

mystic leaf
#

I'm going to be distracted updating the example projects for a bit it looks like.

#

That's great! The .so is called .pyd on windows.

#

So it's one directory too high.

twilit jetty
#

...this was the result of just installing (still had to use ninja). So that's liekely caused by my cmake, let me check.

mystic leaf
#

Actually, I think that looks right, that's thermal_comfort/_thermal_comfort.pyd - though it's missing the SOABI.

#

_thermal_comfort.cp313-win_amd64.pyd or similar

#

It's trying to open the module, since it knows it's a DLL load... Why is there a dir with the same name, actually?

#

Having a file and dir with the same name is challenging with the Python import system.

twilit jetty
mystic leaf
#

Ahh, I guess I do that too in boost-histogram

twilit jetty
#

on linux

venv/lib/python3.13/site-packages/thermal_comfort
β”œβ”€β”€ __init__.py
β”œβ”€β”€ models.py
β”œβ”€β”€ py.typed
β”œβ”€β”€ _thermal_comfort
β”‚   β”œβ”€β”€ __init__.pyi
β”‚   └── thermal_comfort_mod.pyi
β”œβ”€β”€ _thermal_comfort.abi3.so
└── utils.py

yeaht, I think that's where I got that from!

twilit jetty
#

The wheel gets the correct tag: thermal_comfort-0.3.4-cp39-abi3-win_amd64.whl but it's wrong in the wheel

if(NOT "${SKBUILD_SABI_COMPONENT}" STREQUAL "")
  python_add_library(
    ${ModuleName}
    MODULE
    "${CMAKE_CURRENT_BINARY_DIR}/${ModuleName}module.c"
    "${CMAKE_CURRENT_BINARY_DIR}/${ModuleName}-f2pywrappers2.f90"
    "${CMAKE_CURRENT_SOURCE_DIR}/src/${ModuleName}.f90"
    WITH_SOABI
    USE_SABI
    3.7)
else()
  python_add_library(
    ${ModuleName} MODULE "${CMAKE_CURRENT_BINARY_DIR}/${ModuleName}module.c"
    "${CMAKE_CURRENT_BINARY_DIR}/${ModuleName}-f2pywrappers2.f90"
    "${CMAKE_CURRENT_SOURCE_DIR}/src/${ModuleName}.f90" WITH_SOABI)
endif()

Here it goes wrong - if remove the first section I correctly get _thermal_comfort.cp313-win_amd64.pyd. But that still does not solve the DLL load error.

Running ldd on the .pyd give be a Bad file descriptor.

Windows is such pain. I can't even clearly see how it is linked...

# objdump -p venv/Lib/site-packages/thermal_comfort/_thermal_comfort.pyd | grep .dll
        DLL Name: python3.dll
        DLL Name: python313.dll
        DLL Name: KERNEL32.dll
        DLL Name: api-ms-win-crt-environment-l1-1-0.dll
        DLL Name: api-ms-win-crt-heap-l1-1-0.dll
        DLL Name: api-ms-win-crt-math-l1-1-0.dll
        DLL Name: api-ms-win-crt-private-l1-1-0.dll
        DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
        DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
        DLL Name: api-ms-win-crt-string-l1-1-0.dll
        DLL Name: api-ms-win-crt-time-l1-1-0.dll
        DLL Name: libgfortran-5.dll

I call it a day for now. Thank you so much for your help so far ❀️ greatly appreciated. I will have another go tomorrow.

mystic leaf
#

Ahh, yes, stable ABI does have an empty or nearly empty SOABI, that's one weird quirk of stable ABI + Windows.

mystic leaf
#

That action activates everything. I've opened an issue asking for some control over activating at least the C/C++ compilers.

whole lagoon
#

Folks interested in cibuildwheel might be interested in this pull request (and new library whichprovides) as well: https://github.com/pypa/auditwheel/pull/577

This pull request will automatically generate SBOM documents to embed within the wheels repaired by auditwheel to track dependencies that have been grafted into the wheel.

GitHub
[DNM] Generate SBOMs for repaired libraries by sethmlarson Β· Pull ...

(Draft, do not merge) This is my initial pull request for adding automatic SBOM generation based on package manager info for libraries that are repaired into wheels. I've tested locally by ...

mystic leaf
#

nist.gov doesn't allow bots now, so moved to bad-ssl for testing ssl, also had to limit click <8.2 due to it breaking typer (for our dependencies, I avoid typer due to being bit by this multiple times - uses too many internals of click).

south oriole
#

Does cibuildwheel support shell expansions in configs written in pyproject.toml? I was working on https://github.com/numpy/numpy/pull/28640 some time ago and I was stuck at the fact that I wasn't able to get pyodide config commands like this

[tool.cibuildwheel.pyodide]
config-settings = "build-dir=build setup-args=--cross-file=$(pyodide config get meson_cross_file) setup-args=-Dblas=none setup-args=-Dlapack=none"

to work, and it doesn't work for the CIBW_CONFIG_SETTINGS_PYODIDE: environment variable case either. Am I doing something wrong, or is this not supported at all?

drifting dagger
#

that isn't supported, we do support shell expansion like this on the environment and the command options like before-build, but not there.

south oriole
drifting dagger
#

hmm. i'd say... if we could add it in a backward-compatible way, maybe! i suppose we could try interpreting those variables as a list of bash-style assignments. Although, the escaping rules do get pretty knarly- see the xfails in the unit tests

south oriole
#

yup, I've seen those – escaping will be a concern especially if this is inside an environment variable

drifting dagger
mystic leaf
#

Maybe we could add a variable in this case?

south oriole
mystic leaf
#

I was thinking a variable with pyodide's options. Ideally it could return a json and we could just provide access to that with a substitution variable.

south oriole
mystic leaf
#

Yes, or {pyodide_config[meson_cross_file]}, dict or namespace, whatever is better. But yes.

#

@drifting dagger The NumPy devs here at PyCon want to have a release of cibuildwheel for the sprints. I think the last PRs that need to go in are the top 3 right now - docs, test-environment, and and the travis fix. Maybe the bottom PR too, Pydodide improvements. What I was thinking is we could do 3.0.0b1 or 3.0.0rc1 and that would give them a tag to work with while we finish off the last few PRs (some of the above might be able to go in, docs is basically done).

south oriole
#

sounds good, I can try this after the Pyodide improvements PR. that one can also go in later today, as I added the cross-build env metadata to github pages to counter the rate limit.

#

a 3.0.0b1/rc1 with it should also help as I'll be able to test it out downstream then!

drifting dagger
drifting dagger
#

I did slightly rush the release notes, will have to revisit when I have more time πŸ™‚

mystic leaf
#

I think test-sources might be a bit broken.

mystic leaf
#

I think we default to arch: auto on Linux? If so, we should probably default to auto64. There are no 2_28 images for the 32-bit linux.

#

We should mention the scientific-python nightly wheels in our docs, it's the official way to get beta Python wheels for numpy and friends

long nacelle
mystic leaf
#

Has it made it to manylinux yet?

#

Unfortunately, the fixes I was hoping for got pushed off to b3 (probably due to PyCon)

drifting dagger
#

not seeing it on manylinux yet

#

not sure if he's is on discord much, but,

#

@opal zenith any chance of a manylinux image update for CPython 3.14.0b2?

drifting dagger
#

@mystic leaf do you have a particular want for a beta release straight away?

#

i was gonna do it later today once we got that 3.14b2

mystic leaf
#

I wanted to try it on numpy, I guess I can just use the hash

drifting dagger
#

but i can do it now if you are dying to get your hands on it πŸ™‚

mystic leaf
#

I think if it works well, we can do a final release fairly soon?

drifting dagger
#

yeah i think so too

mystic leaf
#

I'm not worried about testing b2 (fixes I really wanted got pushed off to b3 anyway), but I do want to test our test-sources changes

drifting dagger
#

could you use a hash then for the test-sources changes? I'll just hold this last beta release for the manylinux update, shouldn't be too long

mystic leaf
#

^

mystic leaf
#

uvx git+https://github.com/pypa/cibuildwheel@63797729570cef6f8a55bec6b331c1e8107abf0d --only cp313-manylinux_x86_64

mystic leaf
#

Seems to be working AFACT on numpy. Tried test-sources = ["pyproject.toml", "pytest.ini", "tools"] and without.

#

Shouldn't the copy happen earlier, though? test-before-command still has to use {project} currently

drifting dagger
#

great! oh, yeah it should be before before-test in my mind too

#

interestingly, before-test runs in project-dir currently

mystic leaf
#

Numpy has before-test = "pip install -r {project}/requirements/test_requirements.txt"

#

Hmm, that's not bad. Guessing not useful on iOS, though.

drifting dagger
#

it runs outside the simulator on ios

#

probably not much use, but at least it's consistent with the other platforms

mystic leaf
#

Maybe that's fine, that way it gets access to all the original files, not just the ones copied in

#

(Though not sure how useful it is in iOS that way)

drifting dagger
#

yeah i suppose it could be used to generate some data that then gets picked up with test-sources

mystic leaf
#

All the images updated locally for me, btw

drifting dagger
#

yeah, the update-dependencies PR is failing and I have run out of time today...

mystic leaf
#

Was trying to add some useful output to the script that does that, but it's not as easy as I thought, so will probalby leave it for now

drifting dagger
#

i'll just release the next beta without 3.14b2

mystic leaf
#

tag order flipped?

drifting dagger
#

needn't have waited πŸ™„

mystic leaf
#

Was there an auditwheel update that flipped the tag order?

#

Our tests shouldn't care what order the tags are in, ideally

#

3 days ago, I bet that's the issue

drifting dagger
#

ahhhh that sounds right

mystic leaf
#

I can see if I can either reorder it or make it not order dependent. "detect architecture/libc from wheel" might add more tags than we expect, didn't check every one.

drifting dagger
#

i just released v3.0.0b3 btw.

mystic leaf
#

packaging.utils.parse_wheel_filename should do it

drifting dagger
#

looks like that's working. it'll need changing across the codebase, though...

mystic leaf
#

There are a lot of lists of wheel names...

drifting dagger
#

yeah haha

#

it could be a util like utils.wheels_equal(actual, expected) ?

mystic leaf
#

I can get to this later, taking my daughter to swim lessons ATM. Probably can make that more reusable since we have it in lots of places. Like making a smart comparable object or something.

#

Yes, something like that

drifting dagger
#

πŸ‘

mystic leaf
#

A smart comparible object wouldn't require code changes, in theory

drifting dagger
#

Yeah... might be a little tricksy for a test, I fear? I tend to think straightforward code is better in tests. I should have some time tomorrow to plod away refactoring if it's useful

mystic leaf
#

I've seen a package that does pretty much exactly this - something like "dirty compare" or similar. I think a custom compare could also provide a useful diagnostic if it fails. Otherwise it's a somewhat messy set of tuples. I'll take a stab at it.

mystic leaf
#

@mayeut sorted the tags, so let's just go with that. I had something nice started, might go back to it in the future.

mystic leaf
#

So the "remaining" things left are

  • Some pyodide updates (IIRC there was a followup planned?)
  • A beta 2 update for iOS binaries
    I could look at multiple commands for iOS quickly, too. Nothing there is critical for 3.0, so I think we are close.
#

Oh, I also want to add docs for getting nightly numpy wheels, too. Not required before a release, though.

#

Once I get pybind11 3.0.0rc2 out, I'll try to get all wheels going with boost-histogram, including using numpy 3.14(t) and iOS (without numpy unless they've added it to the nightlies, which I don't think they have)

#

That will be a good test along with numpy and astropy which look good

mystic leaf
#

Pushed a b4 release, hope you don't mind, I'm updating numpy and wanted 3.14b2 to make the PR more enticing πŸ™‚

mystic leaf
mystic leaf
#

By the way, I think the changelog is missing some things, like the Python 3.11+ requirement and the defaults updates for manylinux and musllinux, also the removal of 3.6 and 3.7

drifting dagger
#

thanks, yeah i did that first beta1 release a bit rushed on the train. I'll integrate those points.

drifting dagger
safe skiff
#

I saw Seth's PyCon talk about SBOMs. it seems like I want auditwheel repair, but it also seems like cibuildwheel does this for me automatically? My wheels don't have the sboms directory Seth showed. What should I do to get them?

mystic leaf
safe skiff
#

Oh, I misunderstood. I thought he said using a newer version of auditwheel would do it.

whole lagoon
#

Yeah the feature isn't available yet. iirc I mentioned it was a feature branch of auditwheel not in auditwheel, sorry for confusion!

safe skiff
#

np, looking forward to it.

whole lagoon
#

I want to land that PR (and I tried to during sprints) but I have not been able to. It's top of my list after I finish writing the language summit posts.

mystic leaf
#

@drifting dagger I used cog's checksum feature, which lets you know if the README block was edited without running cog. Make sure you rerun the pre-commit instead of manually editing one of the generated blocks. πŸ™‚

(I can disable that by removing -c, but I think it's nice to have)

drifting dagger
#

Yeah let's stick with it, I use the pre-commit git integration but I added that commit before the cog change landed so the rebase messed it up

mystic leaf
#

Made two more small-ish PRs that would be nice for 3.0 - a schema update, and multi-command iOS.

mystic leaf
#

I want to get my boost-histogram PR working, then I'll be happy with it. I'll prepare my blog post based on that, and possibly add some documentation (like how to get numpy 3.14 from the scientific-python nightlies).

drifting dagger
#

i wanna get an RC out today, I think. I'll take a swing at that ios PR, see if I can get it in before.

drifting dagger
#

not being able to set IPHONE_DEPLOYMENT_TARGET is gonna be a showstopper for many, i think.

#

also, just fyi i'm gonna be going on holiday on sunday for a week, so my available time will reduce

#

was hoping to get it out before then !

mystic leaf
#

I'll try to see if I can get my example, docs, and blogpost ready. Don't know what the eta for the next iOS binary is; that would be really nice to have for people wanting to try out the iOS support. It looks like you can't build pybind11 projects or numpy without it.

mystic leaf
#

(My boost-histogram PR is where I'm testing everything together is at https://github.com/scikit-hep/boost-histogram/pull/1016 - I've fixing GraalPy support in scikit-build-core, iOS support in pybind11, and test-sources in cibuildwheel from that. πŸ™‚ I'll use that as the basis for the blogpost. I'm making sure I have examples for how to get numpy binaries for the various platforms).

#

Do we want the color docs PR?

drifting dagger
#

i didn't realise that was ready - yes we can put that in

mystic leaf
#

Okay. Ready for an RC, I think. Only thing left is some docs, and maybe that iOS update?

mystic leaf
#

I believe the test environment does not inherit from the original environment, which I find odd and I think is a backward incompatible change. Shouldn’t it inherit, and we could add a build-environment if there was a reason to have build only variables in the future (that need to be undefined)?

#

(Noticed because setting variables for indexes for NumPy on Andriod, GraalPy, Python 3.14 and iOS needs to be in both environments - at least I think that't it, testing now)

mystic leaf
#

No, I think it's working that way. Not sure why it's not finding numpy yet. iOS is working. It's getting a read timeout error for the nightly wheels. Okay, I've got it mostly working now, and don't think anything else is cibuildwheels fault. Finishing up.

mystic leaf
#

@drifting dagger I can make a beta or rc release if you want me to.

drifting dagger
#

Certainly my intention when adding that feature was that the test environment inherits everything that was set in the build environment. I didn't quite follow your second message, did you find that it's doing something else?

mystic leaf
#

No, my confusion was due to a timeout accessing the index. It's doing the right (as in what I'd expect) thing.

drifting dagger
#

I guess it's probably a beta still, given that we don't intend to ship without the iOS update

mystic leaf
#

Do you want me to add a pyodide prelease flag? Someone was asking for 0.28. I'm not sure they understood that 0.28 isn't abi stable, but until wheels are accepted on PyPI, that's not too big of a deal

#

Also fine to just wait on that, people can use the branch if they need it

#

I am happy to call it either, if you want beta 5, that's fine. I think it's close enough to the final release that RC would be okay, but yes we do plan on one more update, though that should basically just be a bugfix dependency update.

#

The full release of 0.28 is on order "weeks" away according to Hood

drifting dagger
mystic leaf
#

(You would probably not like our pybind11 release candidates, we are litterally bumping the ABI in them at this point πŸ˜‰ )

drifting dagger
drifting dagger
#

(Or maybe that was a vinyl thing!)

mystic leaf
#

IIRC Apple (used to?) has GM's.

#

But a GM isn't numbered, and RC's do have numbers. πŸ™‚

mystic leaf
#

graalpy is missing from our schema

mystic leaf
#

The anchors are misaligned. I think they are calculated before the table at the top is injected. (options page)

Also, I think we should add a star or something on the options page, it's the most important page and now it's not so obvous for someone looking at the docs.

mystic leaf
#

Okay, I'll make a dev release soon. Probably will just go with beta 5

mystic leaf
#

And

A newer version of python3 (v3.13.2) is already installed.
Use --allow-downgrade or --force to attempt to install older versions.
Failed to install python because a previous dependency failed.

#

I don't see a build_script, though. I can add the --allow-downgrade.

mystic leaf
#

The warning is hardcoded in Runner's code and the build_script have nothing to do with any of names used in .gitlab-ci.yml.
Ah, maybe the warning isn't on us, then.

drifting dagger
#

ah, i do see it on safari

drifting dagger
#

Also, I think we should add a star or something on the options page, it's the most important page and now it's not so obvous for someone looking at the docs.

Yeah... perhaps we should raise it up to the top of the reference section

mystic leaf
#

Part of the problem for me is the "reference" section is often just auto-generated docstring-based filler that's not very useful. It would be nice to have something to help let users know it's worth investigating.

mystic leaf
#

Since we are waiting for a new iOS support package, and it looks like Android is ready (and Malcolm stated ""), I'd be willing to accept Android into 3.0 if I can get my test cases (pybind11 and boost-histogram passing).

drifting dagger
#

I think 3.0 is ready now. I don't have time at the moment to review it properly, so think that adding android in would be a delay. My preference would be to leave that until v3.1 so we're not rushing.

#

does that sound alright @mystic leaf ? and is there anything else you want to flag for v3.0?

#

otherwise i think we're ready to do the final release?

mystic leaf
#

I think it was just the update to pyodide-build that I’ve added to the dep update pr

#

If I have time, I might try to get one more small docs update in

mystic leaf
#

Cirrus CI Windows is failing, trying to run GraalPy and something about the path and a trailing character is failing. GraalPy on windows is pretty broken

#

Not important, that's just why there's a red x on our main branch.

#

https://iscinumpy.dev/post/cibuildwheel-3-0-0/

ISciNumPy.dev
🎑 cibuildwheel 3.0

cibuildwheel 3.0 is out, with some very big additions. We’ve added GraalPy,
Python 3.14 (and 3.14t) betas, and iOS support! We’ve got several new options:
test-sources, test-environment, and pyodide-version. We now fully use
enable, PyPy requires an enable, and we no longer inject setuptools and wheel
in build environments. Defaults have cha...

#

(Oops, I should edit the "is out" part)

drifting dagger
#

Nice! Great summary of the changes!

#

As a side effect, we have the extra leeway now test on pre-release 3.14 as host Python too
Little typo here

#

If your tests can be run directly from the source directory, you can set this to ["*"].
I think that this wasn't implemented because it ended up quite error-prone

#

On iOS

#

I see another iOS issue has come in... we could call the iOS support 'experimental' for now as it seems like it's surfacing quite a few issues

drifting dagger
#

i just pushed 3.0.0rc1

mystic leaf
#

In the worst case we can roll back to the version that works, and call it experimental

mystic leaf
#

Pushed rc2 with the iOS support package update, will test.

mystic leaf
#

That minor pyodide issue remains, but I think it's fine (it might only be test-groups, which is easy to workaround). iOS seems to be working well. I have one warning docs PR.

mystic leaf
#

@drifting dagger I’m happy with the current state. Let me know if you need me to do anything.

drifting dagger
#

I'm travelling today so probably won't have time to do the release, so if you want to do the honours, please do!

#

But, one thing I realise we should discuss is i686

#

I think given it is now falling behind on manylinux images, we shouldn't be including it in auto

#

I remember you did raise this a while back but I missed it

#

With it being on a different OS to the other archs, I bet it's gonna cause issues for many packagers.

Collateral damage would be musllinux i686. But who is running 32bit Linux these days anyway?

I think we could either a) pull it from auto now, or b) include a note in the release notes that we will remove it from auto in 3.1.

#

I am kicking myself for not thinking of this sooner in the release process ! (Especially after blathering on about release candidates!!! πŸ˜› ) but 3.0 is a great opportunity to do such a thing.

drifting dagger
#

I'm flying the rest of today home from my holidays. If you're happy with the above henryiii and want to push the final release that's good with me! Otherwise I will do it on Sunday.

mystic leaf
mystic leaf
#

@drifting dagger what is CI.md for? Is it used anywhere?

mystic leaf
#

Though I've ported the key change to the 32-bit linux PR

mystic leaf
#

I've pulled out the CI change so that's easier to get in. Trying to work around the GraalPy bug.

drifting dagger
mystic leaf
#

Windows cert error on Cirrus. The first line (in test_ssl) doesn't check certs, but the second one uses the default, which does. What should we do with that?

drifting dagger
#

just taking a look...

#

mayeut managed to fix it by adding a command forcing the system certs to update

#

But worth checking if there's a new cirrus image first i reckon

#

that would be an easier fix

mystic leaf
#

Ah, great, I was looking for that, forgot which CI it was on.

#

Docs still have 2019 (and there's even a mention of 2016!)

#

The repo I found hasn't been touched in 4 years (adding vs2022 was the last commit)

mystic leaf
#

Got it working on Windows. πŸ™‚ I'll clean up that PR

mystic leaf
drifting dagger
#

Ya, looks good to me

#

I think we're ready for another rc release. I'll do it in the morning unless you get to it first @mystic leaf

mystic leaf
#

I can probably get the RC out tonight. Sooner == sooner release. πŸ™‚

mystic leaf
#

Pushed RC 3, and update the release notes issue comment and my blog post for rc3

mystic leaf
#

IMO, you can release 3.0.0 final whenever you want. There's a minor ci PR and docs PR.

drifting dagger
#

Agreed, I think we're basically there

#

*actually there!

#

I'll push the release at around 1400 UTC

#

your release notes look great henryiii, i'll use those

drifting dagger
mystic leaf
#

That means we are now in free-threading phase II, is no longer experimental in 3.14 and is officially supported. Should we enable free-threading by default with 3.14 once we update to beta 3 (no enable required)? I'm thinking yes.

drifting dagger
#

With these recommendations and the acceptance of this PEP, we as the Python developer community should broadly advertise that free-threading is a supported Python build option now and into the future, and that it will not be removed without a proper deprecation schedule.

Yeah it sure looks like that's the official advice

#

I'm down with that. Would that only affect 3.14 though? So we'd keep the flag for 3.13 free threading?

mystic leaf
#

I think so

drifting dagger
#

that change should probably wait for a v3.1 of cibuildwheel, but we could ship beta3 in a point release

mystic leaf
#

Should we go ahead and ship a patch release for beta 3?

#

And we can change the free-threading default behavior for rc1 (maybe 3.2, but that might actually be 3.1)

mystic leaf
mystic leaf
#

@lavish brook boost-histogram fails on iOS 3.14, it reports it can't find /private/var/folders/y6/nj790rtn62lfktb1sh__79hc0000gn/T/build-env-r7hap9z2/include/python3.14

lavish brook
#

@mystic leaf Interesting... we had a version of that previously, didn't we (possibly on 3.13?)

mystic leaf
#

I think so

lavish brook
#

What support revision is being used?

mystic leaf
#

It would have had to be 3.13 πŸ™‚

lavish brook
#

True πŸ™‚

#

Is the build using 3.14-b4 or 3.14-b5 ?

mystic leaf
#

It's the most recent cibuildwheel release, looking for it

lavish brook
#

Hrm - that should be b5...

mystic leaf
#

Yes, b5

lavish brook
#

But the 3.13 builds are working...

mystic leaf
#

3.14.0t b3 is also failing in tests on Intel macOS, I'm guessing/hoping maybe due to an ABI change and NumPy using b2, unrelated to this, ignore that failure πŸ™‚

#

Yes, it's only 3.14

lavish brook
#

I wonder if this might be related to some of the sysconfig changes in 3.14, and there being another path (or another way of setting the include path) that needs to be accomodated

mystic leaf
#

Quite possible

lavish brook
#

Ok - I'm currently getting my ducks in a row for EuroPython (which has revealed it's own set of problems); can I ask you to log that somewhere so I can take a look when I get a chance?

mystic leaf
#

Sure, where?

lavish brook
#

cibuildwheel is as good as anywhere - it's unlikely to be a scikit/boost-specific issue; if the sysconfig include path isn't being exposed correctly, the fix will be in the iOS support package, but there will be a cibuildwheel revision bump needed to fix it.

dawn inlet
#

Hi, I run cwbuildwheel trouhh pipx and my building system use scikit-build-core to compile a library used by my package. Is there any classical method to stop and enter in a subprocess of compilation. I could modify to provoke an error, but sadly scikit-build-core does not give me a prompt when it encouters an error... πŸ™

boreal stratus
#

Depends on which stage (python code, cmake configure, cmake build, cibuildwheel test) it is failing at. Also, specifically within cibuildwheel or locally as well?

dawn inlet
#

Indeed it does not fail(- I can do it artificially) but i want to stop at the very beginning of the make compilation (after the generation of some sources files to inspect them)

boreal stratus
#

No such feature that I could find, but it might be implementable if any of the pip/uv/build frontends can forward stdin to the build backend (scikit-build-core)

#

In principle it is also possible to put it in an infinite loop listening for a file, but probably we could offer other ways to interact instead. We wanted at some point to expose each build step via a CLI, maybe we could revitalize that concept

dawn inlet
#

It is nice to be fair with your users. For my point of view, I was searching for a quick hack to enter in the process, possibly using gdb or pdb, handwritten infinite loop added by hand or other tricks. But apparently i do not found a standard method. I will try to patch the CMake files and dump files contents using cmake commands but it is not very handy

boreal stratus
#

Curious, overwriting the build-dir is not an option?

dawn inlet
#

build-dir is an option of which software : scikit-build-core ?

boreal stratus
#

Maybe more readable on how to use here

dawn inlet
#

@boreal stratus : Thank a lot, it is very helpful!

#

it works out of pipx, now I must be able to enter in the isolated environment to look at these produced files. It is not anymore a probleme of misuse of scikit-build-core, now I must find how to debug a pipx process πŸ˜„

boreal stratus
#

You mean the files for these build-dir? You should be able to make it an absolute path and put them somewhere predictable

#

I did manage to hook up the IDE's debugger when building with --no-build-isolation if you need to debug the python path

dawn inlet
#

I make a ctrl-z during the compilation and connect to docker with docker -it docker_id sh. Thanks to build-dir option, I could look at the generated files

boreal stratus
#

Something something about how many ways you can do something to a cat πŸ˜›

dawn inlet
#

another question about cbuildwheel with docker : is it possible to parametrize the amount of CPU and memory allocated to docker by the cibuildwheel. I feel that processes running into docker are very slow, although the load of my computer remains low

boreal stratus
#

I don't even know how you would do that in docker/podman

#

Looking at the flags in podman run, it looks really complex

mystic leaf
#

Note from SciPy: having a fuzzy match error message on --only would be useful.

mystic leaf
#

FYI, we are about a week out from RC 1, I think.

vivid flax
#

yes, 3.14 RC 1 scheduled for Tuesday, 2025-07-22

mystic leaf
#

I wonder if it was better for NumPy beacuse they are 3.11+ already. Sadly people aren't setting the only or prefer binary flags when installing.

mystic leaf
#

RC1 is out! Let's get a release soon. I think Android is ready to merge.

tropic galleon
#

Chuck is already champing at the bit to upload numpy wheels once you get a release done πŸ™‚

mystic leaf
#

Sweet. πŸ™‚ I think manylinux is ready.

mystic leaf
#

@drifting dagger Once CI passes I’ll be merging the three ready PRs unless there are objections!

mystic leaf
#

(Android, 3.14 default, and a pre-commit bump)