I can check, but I disabled this because it was blocking the release to PyPI. I will need to double-check to see what wasn't working.

According to my commit message, "Building cp313t wheels requires Cython 3.1, which hasn't been released." I will take a look and see what scipy is doing.

Here is the action failure https://github.com/scikit-image/scikit-image/actions/runs/11204502935/job/31142967402

That log has disappeared so not sure what went wrong or what changed after the initial PR that added nightly wheels.

Here is what NumPy does (and SciPy mirrors that):

(1) in the wheel build job, disable build isolation:
https://github.com/numpy/numpy/blob/11cc665f85fb1038cc2a5b2bdb64a1255215d651/.github/workflows/wheels.yml#L164-L168

(2) in that same wheels.yml job, a few lines down, ensure CIBW_FREE_THREADED_SUPPORT: True is set when cibuildwheel is invoked.

(3) in the shell script that runs before cibuildwheel is invoked (as configued in pyproject.toml, install the necessary build dependencies, and pull in Cython nightly:
https://github.com/numpy/numpy/blob/11cc665f85fb1038cc2a5b2bdb64a1255215d651/tools/wheels/cibw_before_build.sh#L56-L63

NumPy, SciPy and PyWavelets all have cp313t wheels up on PyPI, so Cython is the only package for which a nightly is still needed.

Thanks, Ralf! I figured it out yesterday in #7575. Side note: there's a new way of specifying free threaded support now, using options.

Thanks, Ralf! I figured it out yesterday in #7575.

Great! You meant gh-7699 here.

Side note: there's a new way of specifying free threaded support now, using options.

If that's used in gh-7699, did you mean CIBW_ENABLE=cpython-freethreading or CIBW_BUILD: ${{ matrix.cibw_python }} with cibw_python equal to "cp313t-*"? Different from CIBW_FREE_THREADED_SUPPORT indeed, I didn't check the cibuildwheel docs yet on latest recommended method.

Sorry, shouldn't respond to these things from a phone; yes, that PR and:

https://cibuildwheel.pypa.io/en/stable/options/#enable