Conversation
Co-authored-by: Mark Kittisopikul <mkitti@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #766 +/- ##
===========================================
+ Coverage 99.96% 100.00% +0.03%
===========================================
Files 64 64
Lines 2789 2804 +15
===========================================
+ Hits 2788 2804 +16
+ Misses 1 0 -1
🚀 New features to boost your workflow:
|
dstansby
left a comment
There was a problem hiding this comment.
LGTM - the new API should definitely be made private, and it would be good to see at least one CI run against Zarr 3.0.x to make sure we're retaining support there.
what's the easiest way to set up a test matrix that includes multiple zarr versions that can be run locally easily? Maybe we need to bite the bullet and bring in #704 |
|
For now, can we not just have one test run on the GH Actions CI that tests against |
sure! can you write it? |
…into handle-zarr-3.1.0
Co-authored-by: David Stansby <dstansby@gmail.com>
…into handle-zarr-3.1.0
|
I added pixi + hatch to pyproject.toml exclusively for running the zarr-python tests against two different versions of zarr-python. We can always add to this later. |
dstansby
left a comment
There was a problem hiding this comment.
Big 👍 for pixi here. A couple of things:
- I think we shouldn't commit a lockfile, see inline comment
- In the test logs the version of Zarr the tests are run with isn't printed, meaning it's not possible to verify tests are being run against 3.0.x and latest zarr. Can you print the Zarr version somehow?
437689f adds a step in CI that lists the deps |
TomNicholas
left a comment
There was a problem hiding this comment.
This is important to get in because currently there is zarr data written in the wild that cannot be read with recent zarr-python versions without this PR.
rabernat
left a comment
There was a problem hiding this comment.
Thanks for making this critical fix. Currently, lots of data that was written by Zarr 3.0 is unreadably by 3.1. That needs to be resolved urgently.
This PR reveals something well known already, which is that the interface between Zarr and Numcodecs is not well defined anymore.
However, I think it's critical to get this PR out asap and deal with that broader question later.
Implements a data type adapter layer for
numcodecs.zarr3. Ensures that zarr data structures get the right data type.this hopefully fixes the breakage caused by the zarr 3.1 release.
TODO: