Support python 3.14

[h-mayorquin]

No description provided.

[chrishalcrow]

From trying locally on macOS: I had to pin pydantic>=2.12. Then everything worked, but no numba support yet. They're aiming for a "few weeks" till release.

[chrishalcrow]

Numba 0.63, which supports 3.14, is out!

[h-mayorquin]

There is some dependency resolution thing remaining, I will take a look.

[chrishalcrow]

Failures were different for all three systems (oi oi oi). Working fine for me locally (mac) with same version of numcodecs as was failing on the ci. Trying to run again... still not working. Hmmm.

[h-mayorquin]

Ok, this is another bullet in the same direction. I investigated and to get this through we need to add zarr 3.0 support : /

[alejoe91]

Depends on #4260

[h-mayorquin]

@alejoe91 @chrishalcrow I took another look at this today. Back in January I concluded that Python 3.14 needed zarr 3, so this PR has been waiting on #4260. As we are doing a patch release, I would like to unblock Python 3.14 for NeuroConv with it. So I want to propose splitting this instead: unblock Python 3.14 now for everything except writing to zarr, and add zarr writing when #4260 is out.

The reason this is cheap is that the zarr 2 stack is barely installable on 3.14 anyway. numcodecs<0.16.0 has no wheels for Python 3.14, only the sdist, so right now a 3.14 install means compiling numcodecs from source.

What the PR does now:

• The pins are split by Python version. Below 3.14 nothing changes (zarr>=2.18,<3 and numcodecs<0.16.0). On 3.14 it installs zarr>=3 and numcodecs>=0.16.5.
• Writing to zarr with zarr 3 raises a clear error that points to Python 3.13 or to another format such as binary_folder. The check is check_zarr_write_is_supported() in core_tools.py, called from the zarr write entry points.
• Reading existing zarr folders works, after a small fix in super_zarr_open for local paths.
• The core tests skip the zarr writing parts on zarr 3, each with a TODO to remove once Support zarr v3 #4260 lands. Locally the core tests pass on 3.14 (348 passed, 46 skipped) and on 3.12 nothing extra is skipped (377 passed, 17 skipped). I have not run the other markers yet, CI will tell.

I also merged main into the branch, it was quite behind.

Would this work for you? @alejoe91 is it OK to land this before #4260? Then #4260 would only need to drop the version markers and the skips. The latter should be easy cake for an agent and this will unblock python 3.14 on neuroconv.

[alejoe91]

could we move this to conftest.py so we don't need to repeat it (and then remove it!) everywhere?

[alejoe91]

@h-mayorquin I think we have to skip the zarr streaming and ibl streaming too (or maybe just not install the ibl libraries for 3.14).

Also added a small comment about centralizing the requires_zarr_mark

[h-mayorquin]

@alejoe91 the checks are green on the last commit.

I did what you asked. requires_zarr_write is now a marker registered in pyproject.toml and skipped from conftest.py, so it is not repeated in the test files anymore. The IBL streaming tests are skipped on Python 3.14, and the zarr streaming tests are skipped with zarr>=3.

The IBL failure is not Python 3.14 itself. one-api 3.4.2 to 3.5.2 pin numpy<2.4, so on 3.14 the resolver went back to one-api 3.4.1, and that one fails with Dataset "*.ap.ch" not found. one-api 3.6.0 came out on the 6th without the pin. I can try removing the IBL skip in a follow up commit to see if it passes.

CI found a few more things that needed a skip or a clear error:

• tridesclous2 and lupin write templates.zarr by default (save_array=True), so on zarr 3 they now raise the zarr write error at the start of the run instead of at the end.
• The template database tests are skipped on zarr 3, probeinterface calls len() on a zarr array in Probe.from_zarr_group.
• The Linux job pins git-annex to 10.20260901 because the latest DataLad package is missing (there is a TODO to remove the pin once that is fixed).

Once this lands, #4260 (Support zarr v3) only needs to drop the version markers and the requires_zarr_write skips.

[alejoe91]

Thanks @h-mayorquin

Looks good to me then!