Add compatibility with Zarr-Python 3.2.0

[maxrjones]

There are some internal changes coming in Zarr-Python that impact VirtualiZarr, which are addressed by this PR.

Acceptance criteria:

• Closes #xxxx
• Tests added
• Tests passing
• No test coverage regression
• Full type hint coverage
• Changes are documented in docs/releases.md
• New functions/methods are listed in an appropriate *.md file under docs/api
• New functionality has documentation

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.35%. Comparing base (1b8abe9) to head (962a371).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #957      +/-   ##
==========================================
+ Coverage   89.30%   89.35%   +0.04%     
==========================================
  Files          33       33              
  Lines        2039     2038       -1     
==========================================
  Hits         1821     1821              
+ Misses        218      217       -1     

Files with missing lines	Coverage Δ
virtualizarr/manifests/array.py	85.00% <100.00%> (+0.62%)	⬆️
virtualizarr/parsers/zarr.py	97.50% <100.00%> (+0.04%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

[maxrjones]

failures should be fixed upstream by earth-mover/icechunk#1937

[TomNicholas]

failures should be fixed upstream by earth-mover/icechunk#1937

Note that this is only for Icechunk 2.0. We actually have the same problem for the latest release of IC 1.0 . But do we care about that?

[TomNicholas]

Also can we perhaps release a patch version of VZ first? We have multiple things going on here:

• Broken sharding feature already released that needs patching
• Compatibility with IC2 (should work out of the box, but should we pin for any reason?)
• Your changes in this PR

[maxrjones]

failures should be fixed upstream by earth-mover/icechunk#1937

Note that this is only for Icechunk 2.0. We actually have the same problem for the latest release of IC 1.0 . But do we care about that?

I think that any release of Icechunk with a fix for the missing readme would solve our CI problems, as long as we don't pin to <2.

[maxrjones]

Also can we perhaps release a patch version of VZ first? We have multiple things going on here:

• Broken sharding feature already released that needs patching
• Compatibility with IC2 (should work out of the box, but should we pin for any reason?)
• Your changes in this PR

I'd support merging and releasing #952 before any other changes. fwiw I don't think it's bad to have merged #897 before the patch release - that's a long overdue bug fix.

[TomNicholas]

I think that any release of Icechunk with a fix for the missing readme would solve our CI problems, as long as we don't pin to <2.

That release should come in a sec / by tomorrow.

I'd support merging and releasing #952 before any other changes. fwiw I don't think it's bad to have merged #897 before the patch release - that's a long overdue bug fix.

Agreed.

[TomNicholas]

Released, so as long as this passes (particularly on min-deps!) then lets go

[TomNicholas]

Maybe we should actually look for specific versions of zarr-python instead of the blind try...except?

[maxrjones]

Zarr-Python uses hatch-vcs, which builds versions from git tags. If a user installs from a git source that does not have the tags fetched, the version can display as a low number despite being based on the most recent commits to main, which breaks the code with an obscure error message. This try...except leads to informative error messages by describing exactly what is needed rather than implicitly relying on the version.

[TomNicholas]

Running the upstream tests shows a breaking change - it seems that zarr now forbids chunks of length 0, which it didn't forbid before?

https://github.com/zarr-developers/VirtualiZarr/actions/runs/24685336933/job/72193091799

AFAICT the Zarr spec does not forbid length-0 chunks, so it's zarr-python that is wrong here?

https://zarr-specs.readthedocs.io/en/latest/v3/chunk-grids/regular-grid/index.html

[maxrjones]

Running the upstream tests shows a breaking change - it seems that zarr now forbids chunks of length 0, which it didn't forbid before?

zarr-developers/VirtualiZarr/actions/runs/24685336933/job/72193091799

AFAICT the Zarr spec does not forbid length-0 chunks, so it's zarr-python that is wrong here?

zarr-specs.readthedocs.io/en/latest/v3/chunk-grids/regular-grid/index.html

This was discussed in zarr-developers/zarr-python#3802 (comment). We leaned towards this being a mistake in the core spec since modular arithmetic is undefined for 0. Please raise an upstream issue if you still think this should be addressed in zarr-python rather than the spec.

[LDeakin]

More context on that

• Zero-sized arrays in zarrs zarrs/zarrs#352
• disallow regular chunk grid with 0-length chunks zarr-python#3711

[TomNicholas]

Thanks for the context guys.

@sharkinsspatial you wrote this test and the fixture it uses - do you have any concerns with HDF compatibility if I simply change the behaviour of the HDFParser to raise on length-0 chunks?