I tried to address the unrelated CI failures in#29008.

It looks like there's a test failure on windows arm64 under free-threading that doesn't occur elsewhere:

================================== FAILURES ===================================  __________________ TestUfunc.test_array_wrap_array_priority ___________________  [gw2] win32 -- Python 3.14.0 C:\Users\runneradmin\AppData\Local\Temp\cibw-run-zl0cw_gz\cp314t-win_arm64\venv-test\Scripts\python.exe    self = <test_ufunc.TestUfunc object at 0x00000338325CA600>        def test_array_wrap_array_priority(self):          class ArrayPriorityBase(np.ndarray):              @classmethod              def __array_wrap__(cls, array, context=None, return_scalar=False):                  return cls                class ArrayPriorityMinus0(ArrayPriorityBase):              __array_priority__ = 0                class ArrayPriorityMinus1000(ArrayPriorityBase):              __array_priority__ = -1000                class ArrayPriorityMinus1000b(ArrayPriorityBase):              __array_priority__ = -1000                class ArrayPriorityMinus2000(ArrayPriorityBase):              __array_priority__ = -2000                x = ArrayPriorityMinus1000(2)          xb = ArrayPriorityMinus1000b(2)          y = ArrayPriorityMinus2000(2)        >       assert np.add(x, y) is ArrayPriorityMinus1000  E       RuntimeWarning: invalid value encountered in add    ArrayPriorityBase = <class 'test_ufunc.TestUfunc.test_array_wrap_array_priority.<locals>.ArrayPriorityBase'>  ArrayPriorityMinus0 = <class 'test_ufunc.TestUfunc.test_array_wrap_array_priority.<locals>.ArrayPriorityMinus0'>  ArrayPriorityMinus1000 = <class 'test_ufunc.TestUfunc.test_array_wrap_array_priority.<locals>.ArrayPriorityMinus1000'>  ArrayPriorityMinus1000b = <class 'test_ufunc.TestUfunc.test_array_wrap_array_priority.<locals>.ArrayPriorityMinus1000b'>  ArrayPriorityMinus2000 = <class 'test_ufunc.TestUfunc.test_array_wrap_array_priority.<locals>.ArrayPriorityMinus2000'>  self       = <test_ufunc.TestUfunc object at 0x00000338325CA600>  x          = ArrayPriorityMinus1000([4.9e-324, 1.2e-322])  xb         = ArrayPriorityMinus1000b([1.5e-323, 4.9e-324])  y          = ArrayPriorityMinus2000([            nan, 2.08600674e-308])    C:\Users\runneradmin\AppData\Local\Temp\cibw-run-zl0cw_gz\cp314t-win_arm64\venv-test\Lib\site-packages\numpy\_core\tests\test_ufunc.py:2130: RuntimeWarning

Other than that things seem to be building and testing correctly.

The way tests run changed significantly in 3.0, to facilitate iOS (and Android). It's more like conda-build now. By default, it runs in the root. If you usesrc/ structure, of course, that's fine. But if you don't, we are hoping to setPYTHONSAFEPATH inpypa/cibuildwheel#2388 which wasn't passing before beta 1 was cut (it is now, though). This should fix any 3.11+ projects, which hopefully covers the old Scientific projects that don't usesrc structure (yet? Though now that you can set this, there's less reason to). I think numpy will work "by default" with this setting. You can also set it yourself, or use the-x version on the command line if you are 3.11+.

There's also a newtest-sources setting, which will copy any globs specified to a new directory, and test there. That's actually much closer to iOS, which has to copy the directory into the emulator, so setting this to just include["tests", "pyproject.toml"] is likely the best path for updating projects. (If this looks familiar, it's the way conda-build/ratter work).

Do either of you happen to know why I had to addcd tools to thecibw_test_command.sh file?

I'm curious what the error was that you got without this line?

I'm curious what the error was that you got without this line?

ImportError: cannot import name 'version' from 'numpy' (consider renaming '/project/numpy/__init__.py' if it has the same name as a library you intended to import)

see e.g.this CI run on my fork of NumPy. Although that said it also looks like it's happening here now - so I guessPYTHONSAFEPATH isn't sufficient to avoid that. I'll go back moving intotools - that's the hacky idiom we use elsewhere in CI.

The pypy3.11 failure is addressed by#29014.

Setting PYTHONSAFEPATH messes up pytest's loading of conftest.py, it seems. Pytest is trying to importnumpy.conftest. Oh, there actually is anumpy.conftest. It's only in the source tree, not in the install tree; PYTHONSAFEPATH is working then and that's what's confusing it.

I tried setting--import-mode=importlib, which I think might have helped, but that's running into an issueERROR - ValueError: option names {'--available-memory'} already added appearing 8 times, so something is rerunning that hook.

I'd like to understand exactly why these things are happening, so will look into it more later. The best solution is probably to usetest-sources, as that will also enable iOS wheels. I'm runninguvx cibuildwheel==3.0.0b1 --only cp313-manylinux_x86_64 to test locally.

I wonder how annoying it would be to bite the bullet and do a mass-rename to ansrc layout.

Probably pretty annoying given the number of open PRs, unfortunately...

It would be nice, though. It would make local running easier. :) The rename might not be that bad as long as no content changes in renamed files, it might be able to track though it.

This looks like a bug in cibuildwheel (or my understanding of how to specify test-sources):

test-sources = ["tools","numpy/conftest.py","pyproject.toml","pytest.ini"]

Successfully installed numpy-2.3.0.dev0    + mkdir -p /tmp/tmp.UKbQJ5C2pd/test_cwd    + mkdir -p /tmp/tmp.UKbQJ5C2pd/test_cwd/toolssh: /tmp/tmp.UKbQJ5C2pd/test_cwd/numpy/conftest.py: No such file or directory                                                             ✕ 16.38scibuildwheel: error: Command ['docker', 'exec', '-i', 'cibuildwheel-800ebe67-e43e-49be-b232-eee7dc55a646', 'sh', '-c', 'cat > /tmp/tmp.UKbQJ5C2pd/test_cwd/numpy/conftest.py'] failed with code 1.

and do a mass-rename to an src layout

IIRC, that possibility was discussed when we began the transition to pytest back in 2017. It was the pytest suggested layout, but would have required a lot of work and been less convenient than keeping the test files together with the source files. The idea of having a separate download required for the tests also did not appeal at that time. Which is a bit ironic given our current desire to reduce wheel size.

I am not opposed to such a massive reorganization, but I don't think this is the time to do it.

This is not the only package with this layout, so we (cibuildwheel) need to figure out what is happening and how best to provide help, a backward compatibility mode, and/or a path forward. I have a backward compatibility idea that I’m gonna propose in a little bit, but first I need to understand exactly how the structure is currently working.

(And I’m only working on this for a few minutes every so often currently)

My personal recommendation is a small unittest based suite inside the package that just validates the build works on that system, and the full pytest suite outside the package. But that doesn’t have anything to do with upgrading to cibuildwheel 3. :)

For now are we ok to upload the wheels generated here with thecd tools hack to the scientific python nightly repository?

I think so, yes. Thecd tools hack is more-or-less what cibuildwheel used to do for you when running your test command.

Ping@charris@rgommers - do you feel comfortable uploading nightly wheels for 3.14? I think this is ready.

I don't have a problem with nightlies, but I don't want them to show up in the released wheels until the first 3.14 rc. Maybe wait until 2.3 is branched, which should be in a day or two. I am also a bit wary of having the cibuildwheel 3.0 beta in the maintenance branch. It looks like an easy backport to make when the time comes.

Happy to wait until after 2.3 is branched.

If the CI can have a different environment for the nightlies, you can only set the enable for the nightly CI.

cibuildwheel 3 (beta or not) makes a few platform changes, like a manylinux and musllinux bump. You can select older ones and get identical output (not musllinux please, 1.1 is pretty dead at this point), but I'd make sure you are happy with what's being produced before committing to 3.

_pytest.pathlib.ImportPathMismatchError: ('numpy.conftest', '/tmp/tmp.EEW3FuSvyg/venv/lib/python3.13/site-packages/numpy/conftest.py', PosixPath('/project/numpy/conftest.py')) is what's showing up with PYTHONSAFEPATH. Going to continue to debug (occasionally), plus we have a bug with test-sources to fix.

Will there not be acibuildwheel 2.2x release with 3.14-dev support?

Will there not be acibuildwheel 2.2x release with 3.14-dev support?

No.

You can get exactly the same builds out of 3.0, just manylinux/musllinux defaults have changed based on announced dates (6+ months). It’s honestly a perfect time for bumping with a new Python version.

We should be able to fix the testing changes, working on understanding numpy’s setup and fixing.

Okay, thanks@henryiii. It was simply the "beta" tag that triggered the question. Normally the new thing is released before the stable series stops working. So I assume the 3.0 release is coming before CPython 3.14.0rc1 and all the dust has settled on the changes in 3.0/main?

We should probably also move tomanylinux_2_28 at the same time. I assume that's the new default anyway in cibuildwheel 3.0 (can't find the docs on that so quickly), xrefhttps://github.com/mayeut/pep600_compliance?tab=readme-ov-file#acceptable-distros-to-build-wheels. This was discussed in a triage meeting about half a year ago; if we do it in this PR the change will only be released in Dec 2025 (Cc@mattip ), which should be fine - and moving for nightlies now gives us time to find potential issues.

We should probably also move to manylinux_2_28

I thought we did that in#28436.

Thanks@charris, you're right - I completely missed that. Sincepyproject.toml already contains:

[tool.cibuildwheel.linux]manylinux-x86_64-image ="manylinux_2_28"manylinux-aarch64-image ="manylinux_2_28"musllinux-x86_64-image ="musllinux_1_2"musllinux-aarch64-image ="musllinux_1_2"

we should be good here.

Normally the new thing is released before the stable series stops working.

The stable series has not stopped working. We'll fix it if it does.

So I assume the 3.0 release is coming before CPython 3.14.0rc1 and all the dust has settled on the changes in 3.0/main?

It should be done before 3.14.0b2 in a couple of weeks, much less than rc1 which is something like 3 months away, yes. I think we are about ~1 week away, assuming no blockers (test-sources not working is already a blocker, to be fair).

If it werereally delayed, yes, we'd try to backport this to 2.x. But I don't think we'll need to.

Since pyproject.toml already contains

Perfect, moving to 3.0 shouldn't change anything then, only defaults are changing (to the values above, except on 32-bit linux).

(Except for the test changes, which we are looking into)

Great, given that timing we should move to 3.0-beta now indeed.

Actually no need to backport this yet - easier to do the 2.3.0 release without it, and backport it once we're releasing for CPython 3.14 (probably will be numpy 2.3.2 or 2.3.3).