refactor: bring in types from zarr-metadata

[d-v-b]

replaces some of our types with exports from zarr-metadata. I expect a few related PRs, alternating between ones like this (importing types) and ones that add missing types to zarr-metadata.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/user-guide/*.md
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

cc @chuckwondo

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.27%. Comparing base (eac9c86) to head (397fb3e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3961      +/-   ##
==========================================
- Coverage   93.28%   93.27%   -0.01%     
==========================================
  Files          87       87              
  Lines       11745    11732      -13     
==========================================
- Hits        10956    10943      -13     
  Misses        789      789              

Files with missing lines	Coverage Δ
src/zarr/codecs/blosc.py	95.74% <100.00%> (-0.03%)	⬇️
src/zarr/codecs/cast_value.py	98.58% <100.00%> (-0.02%)	⬇️
src/zarr/core/metadata/v2.py	88.95% <100.00%> (-0.07%)	⬇️
src/zarr/core/metadata/v3.py	93.69% <100.00%> (-0.17%)	⬇️

🚀 New features to boost your workflow:

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

[ilan-gold]

So development of these packages will proceed entirely independently and one is not developed against another? Or is there a secrete setting somewhere that enables this to be linked?

[d-v-b]

can you explain what you mean? zarr-metadata is on pypi, which is how we expect people who install zarr-python to get that package. zarr-metadata will be developed with the goal of primarily supporting zarr-python, and when new versions of zarr-metadata are released, we would update zarr-python to depend on them.

[ilan-gold]

My concern is that without an upper bound, something could be developed in zarr-metadata that breaks zarr-python. So maybe it makes sense to have a hatch job added to the test suite that tests zarr-python against what is in zarr-metadata?

[d-v-b]

yeah that's a good idea! this should run whenever we make changes to zarr-metadata. I'll add that to this PR.

[d-v-b]

i made a few changes in this area:

1. we put an upper bound on the supported version of zarr-metadata
2. we ensure that the default zarr-python tests run on the package-local zarr-metadata (so we don't need an explicit upstream test)
3. we ensure that our min deps tests run on the pypi-installed zarr-metadata (so we know if we break compatibility with the oldest version on pypi). We use a pre-commit check to ensure that the version of zarr-metadata pinned in the min deps environment matches the lowest version zarr-python is compatible with (i.e., if we bump the minimum version of zarr-metadata in our main deps, we see a pre-commit failure if we don't also bump the version pinned in the min deps environment)