feat: add support for Python 3.14 in workflows and classifiers

[kevinzunigacuellar]

Description

Following up with releasing conda build for python 3.14 conda-forge/dandi-feedstock#156

• updated classifiers to include python 3.14
• updated python matrix in tests to include python 3.14
• updated latest version special jobs from 3.13 to 3.14

[CodyCBakerPhD]

No description provided.

As a matter of practice, please include a useful description to the PR (which workflows needed updating, did you run it locally, on your own fork's actions, links to git logs, etc etc)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.27%. Comparing base (0af950f) to head (792bdc9).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1838      +/-   ##
==========================================
- Coverage   76.28%   76.27%   -0.01%     
==========================================
  Files          87       87              
  Lines       12484    12484              
==========================================
- Hits         9523     9522       -1     
- Misses       2961     2962       +1     

Flag	Coverage Δ
unittests	76.27% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[yarikoptic]

Unfortunately numcodecs seems not ready yet for the glorious 3.14 on Mac, needs "research"

[CodyCBakerPhD]

Unfortunately numcodecs seems not ready yet for the glorious 3.14 on Mac, needs "research"

I keep hearing that about NWB/DANDI environments but nwb2bids has no issue and I recall Heberto resolved it on the video widgets as well... will try to report back with some links

[kevinzunigacuellar]

Seems that whl for 3.14 for numcodecs is available since 0.16.4

[yarikoptic]

I am away from computer ATM - we need to check why we limited to start with, usually doing so when new versions are incompatible or known to be defective or cause other issues

[CodyCBakerPhD]

Last change on our end was back for Kabi: #1653 (comment)

Which did something to a test on a Zarr chunk with Blosc compression

Maybe it has 'worked itself out' since then? What happens if we release the lock entirely

[kevinzunigacuellar]

Maybe it has 'worked itself out' since then? What happens if we release the lock entirely

We could try that, but I think the zarr has a constrain to lower than 0.16 for v2

├── zarr [required: >=2.10,<=3.1.5, installed: 2.18.7]
│   ├── asciitree [required: Any, installed: 0.3.3]
│   ├── numpy [required: >=1.24, installed: 2.4.4]
│   ├── fasteners [required: Any, installed: 0.20]
│   └── numcodecs [required: >=0.10.0,<0.16,!=0.14.1,!=0.14.0, installed: 0.15.1]

[kevinzunigacuellar]

Summary of my findings:

The failure with numcodecs appears to be due to the absence of a compatible wheel. Since we are currently using Zarr v2, it requires numcodecs versions below 0.16. However, those versions were released before Python 3.14 and do not provide prebuilt wheels for it, which leads to installation issues in this environment.

Zarr v3, on the other hand, has more flexible dependency requirements and supports newer numcodecs versions that are compatible with Python 3.14 and provide wheel distributions.

Given this, I believe the issue is blocked pending a migration to Zarr v3.

Happy to help with the migration in separate PR. Let me kwon how you want to proceed.

[yarikoptic]

thanks, for zarr v3 we even merged recently

• zarr 3 support #1609

and pin was added in 410a8cd from

• Expand Zarr dependency to include version 3 #1653

as a quick and dirty "try and see" idea pointing to another FTBFS

• cannot import name 'cbuffer_sizes' from 'numcodecs.blosc' zarr-developers/numcodecs#721

but here we fail differently if exact 0.16 is allowed , and anyways -- IMHO no need to cap then at 0.16 exactly -- let's try to relax and see if helps OSX.

[kevinzunigacuellar]

Took another look. this seems to be blocked by the Zarr v3 migration upstream, not within dandi-cli itself.

Specifically, hdmf_zarr currently requires zarr<3 and numcodecs<0.16, which forces the resolver to stay on older versions even if constraints are relaxed in dandi.

There is already an open PR in hdmf_zarr adding Zarr v3 support, which should also allow newer numcodecs versions (>0.16) once released. Until that lands (and is adopted by nwbinspector), relaxing the numcodecs constraint here won’t have any effect.

For reference here is the current resolution:

zarr==2.18.7
├── hdmf_zarr==0.12.0 [requires: zarr>=2.18.0,<3.0]
│   └── nwbinspector==0.7.1 [requires: hdmf_zarr]
│       └── dandi==0.74.3
└── dandi==0.74.3 [requires: zarr>=2.10,<=3.1.5]

numcodecs==0.15.1
├── hdmf_zarr==0.12.0 [requires: numcodecs>=0.12.0,<0.16.0]
├── zarr==2.18.7 [requires: numcodecs>=0.10.0,<0.16]
└── dandi==0.74.3 [requires: numcodecs<0.16]

Also zarr v3 drops support for py 3.10 so minimun version will also have to be updated to 3.11

[yarikoptic]

thank you @kevinzunigacuellar , I followed up on that PR, and adjusted labels. I will move it into draft for now as well since we can't really proceed ATM with this :-/