V0.11.1 storage options

[joshua-gould]

ome-zarr==0.11.1 (the last version that supports zarr<3) has issues writing arrays for dask>2025.11.0. For users that have not upgraded from zarr 2 to 3, maintaining this version is important for latest dask versions.

This fix has been tested against dask==2026.3.0 and dask==2025.11.0

Example of writing with dask==2026.3.0 and zarr < 3 failing silently using S3 URL

import sys

import dask.array as da
import zarr
from zarr.storage import FSStore

url = sys.argv[1] # e.g. s3://foo

image = da.ones((10, 10)).rechunk((2, 2))

storage_options = {}
root = zarr.open(url, mode="a")

# works if url is a local URL
# completes successfully without writing array if url is S3 URL
# writes successfully if storage_options is None instead of empty dict

da.to_zarr(
    arr=image,
    url=root.store,
    component="foo",
    storage_options=storage_options,
)

# works with local and S3 URL
da.to_zarr(
    arr=image,
    url=FSStore(url, **storage_options),
    component="foo2",
)

[will-moore]

Hi @joshua-gould, thanks for the PR.
Are you proposing changes to a branch/fork of ome-zarr-py v0.11.1 here?
I don't think we'd want to support the maintenance of multiple branches.

Do you need to work with zarr-python v2 because of compatibility for some other library, or do you simply need to write Zarr v2 (which is still supported)?

[joshua-gould]

This pull request is for ome-zarr-py v0.11.1 (the latest ome-zarr version that is compatible with zarr<3).
We need to keep zarr<3 because of compatibility with another library. Thanks.

[will-moore]

I'm afraid we don't have the ability/resources to maintain multiple development branches.
zarr-python 3.0.0 has been out since Jan 2025 and most libraries are compatible with it now, so we are not aware of a big need for this from our users.

If you are able to install and use ome-zarr-py from this branch then hopefully that will allow you to keep working with the tools that you need (until such time as they are updated to work with current zarr-python).

[joshua-gould]

Would you be open to a pull request off the master branch that adds support for python zarr v2 or v3?

[will-moore]

I appreciate the offer, but my personal feeling is that this would be a lot of work (it was a ton of work to migrate to zarr-python v3 originally - 91 commits), both to implement and maintain. Maybe I'm missing something?
cc @jo-mueller?

[will-moore]

Surely it would be less work to implement zarr-python v3 support in whatever tool is lacking it?

[jo-mueller]

@joshua-gould I'm afraid I'm with @will-moore here. But looking at your issue, I think it's maybe not so much a zarr v2/v3 issue, but rather an issue with three particular dask versions (2025.11, 2026.1.0 and 2026.1.1) which came with a different syntax on how to pass on zarr storage arguments to zarr. So naturally, that would run into conflicts with the storage_options keyword in ome-zarr-py.

I think there is a chance that #534 will fix your issue, as it will pin the allowed dask versions back (or forward, respectively) to versions that evade this problem.

[melonora]

@joshua-gould Please see #534. This increases the range of support for dask versions 2025.2.0-2025.11.0 and 2026.3.0 and up