If having the configuration in pyproject.toml is not something that would be considered, it should be easy to move it to tools/wheels/cibuildwheel.toml.

This PR makes sense. How sure are you that the new code is equivalent to the old? Can we somehow compare the number of tests run or some other parameter that would give us confidence that this is correct?

I will check number of tests and environment for all wheels.

@mattip, a deeper look into what you asked for showed some diffs:

1. On Linux (both Travis-CI & GHA), wheels are now built with NPY_USE_BLAS_ILP64="1". I missed the fact that the environment variable was not passed to the manylinux containers in the current code in main. However, when looking at MacPython/numpy-wheels, official wheels are built with NPY_USE_BLAS_ILP64="1". This raises 2 questions:
   1. Was that an oversight in BLD Uses cibuildwheel for linux + osx wheels [cd build] #20102 ?
   2. If so, shall I open a PR to correct this first ?
2. There's a difference in test executions for cp3*-win32 (more skipped tests for some reason), I'll look further into this.

There's a difference in test executions for cp3*-win32 (more skipped tests for some reason), I'll look further into this.

cp39-win32 & cp310-win32 are in fact showing the same tests results. It was only for cp38-win32 because it seems that GHA runners do not all offer the same level of SIMD support and thus, some tests were skipped on cp38-win32 in this PR.

wheels are now built with NPY_USE_BLAS_ILP64="1"

That was an oversight in the previous cibuildwheel work. Thanks for checking. Since we will merge this, no backport fix is needed, right?

Since we will merge this, no backport fix is needed, right?

Right, just asking if you wanted to split this in 2 to split the NPY_USE_BLAS_ILP64=1 fix from the configuration refactor.
Since the cibuildwheel workflows are not used to build official wheels yet, it might not be necessary (as you said, no backport needed) and it might just be easier to merge as-is.

Thanks @mayeut