python312Packages.zarr: 2.18.3 -> 3.0.4

[bcdarwin]

Currently draft since at least the following packages need to be updated upstream to the Zarr 3.x. API:

• python312Packages.tifffile: Zarr v3 compatibility? cgohlke/tifffile#282
• python312Packages.multiscale-spatial-image: zarr 3 spatial-image/multiscale-spatial-image#108
• python312Packages.ome-zarr: Zarr v3 ome/ome-zarr-py#404
• python312Packages.reproject

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[dotlambda]

• python312Packages.multiscale-spatial-image

I can't find an upstream issue for that. Mind opening one?

[doronbehar]

• python312Packages.multiscale-spatial-image

I can't find an upstream issue for that. Mind opening one?

Done, also for tifffile, and updated the top comment of the PR. Also, I pushed a few more commits related to the main topic of the PR. I also added there reproject which is another direct dependency of zarr.

[doronbehar]

After working a bit with the patch here and with zarr v3 directly, I noticed that many features of it are missing in comparison to version 2.x. Even if the dependencies mentioned in the PR's top comment will adapt to v3, I think we should still have a zarr2 attribute and perform a gradual transition. Do you think @dotlambda maybe we should at the moment create a zarr3 (and zarr2) attribute(s) and later on handle the dependencies? In a similar fashion to what we did with Numpy.. It would be nice to let Nixpkgs users be able to use zarr3 if they want to without maintaining a fork. I anticipate that the dependent packages will take time to adapt anyway, also possibly due to missing features.