I did remove zarr_read_kwargs. Not sure if I should add a deprecation for it already even though it was there just for a very short time.

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

0 tests  ±0   0 ✅ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit e6bb507. ± Comparison against base commit 6dff73f.

♻️ This comment has been updated with latest results.

@melonora I think that this change is good but I wonder if you actually need to deprecate kwargs?

It seems like now the kwargs are actually being used as documented. That and just passing keyword arguments is cleaner than creating a dict.

That would indeed not be required. It could be unpacked with that name though just for more clarity and I wiuld also update the docstring with the actual documentation links. I do not have access to my pc at the moment, but will do so later

@CSSFrancis changes have been performed

@jacobtomlinson Do you see any further action points for me to do in this PR?

FYI @will-moore

@TomAugspurger Do you think this PR is good to go so it could be included in the first release of 2026?

Let's get this or #12233 in today (cc @joshua-gould).

Anybody mind summarizing the differences? My main goal is to ensure that code from dask<=2025.11.0 continues to work. If we can also make code from dask==2025.12.0 then great, but IMO that's secondary.

@TomAugspurger in #12333 read_kwargs specified in **kwargs, get reassigned to zarr_array_kwargs. This means that mode argument can now be in zarr_array_kwargs but then wouldn't be passed on to arr_store = _setup_zarr_store(url, storage_options, **zarr_read_kwargs), which has not been changed. I don't think that would be correct behaviour but I could be wrong. It isn't in the spirit of **kwargs in the PR here where these are the arguments to Group.create_array alone.

Sorry, I'm finding it a bit hard to follow all the changes :/

Does this come down to fundamental ambiguity / disagreements over what **kwargs used to mean?

@TomAugspurger if you would like we could have a quick minicall (15 min would be enough).

But in short yes, in the othere PR the read arguments get mixed with the actual Group.create_array arguments. In this PR given that the only valid argument is mode I just added that parameter so now **kwargs are really only arguments for create_array. Also in the other PR if you pass mode in **kwargs it will have no effect because it is not passed on where it should be, which is _setup_zarr_store(url, storage_options, **zarr_read_kwargs).

However, this PR is not fully backward compatible as far as I am aware if somebody was passing on read_only in **kwargs. The reason why I removed it is because I don't know why somebody would make it read_only when writing. The mode argument I kept because there are multiple modes allowing for writing.

@TomAugspurger I will try to be there with the next community meeting if that is more suitable. I saw that 2026.1.0 got released, but I think it would be good to get this in sooner rather than later given the API change. We don't want people to adopt the current API too much if it gets switched back to **kwargs.

The change that required usage of zarr_array_kwargs to pass dimension_names when writing to zarr caused ome-zarr-py to write invalid OME-Zarr (since dimension_names were missing).

This was fixed in ome/ome-zarr-py#511 but hasn't been released yet, so it's possible that some users could be writing invalid OME-Zarr now.
I'm not sure if zarr_array_kwargs is likely to change again (or are you only discussing zarr_read_kwargs?) but either way, we should release ome-zarr-py soon so as to avoid users writing invalid data. cc @joshmoore

@will-moore yes, working on ome-zarr-py right now but I would have liked to skip these dask versions if this PR was to be merged given the different API. After this **zarr_array_kwargs is not looking to be changed. The contents within **zarr_array_kwargs could change if it is changed upstream in zarr-python. Zarr_array_kwargs are directly the arguments of Group.create_array.

@will-moore note that that change regarding "dimension_names" is only when writing zarr_format v3 arrays, not v2.

Thanks @melonora. Last request: can you add a note to the changelog with a summary of the changes here. I want to provide clear guidance to users about what they need to do, depending on their version of dask.

Of course, will add it when I get to my laptop

@TomAugspurger Done, can you please let me know if it is clear to you?

Thanks @melonora.

@joshua-gould are you able to check whether this fixes the issue you ran into?

Thanks @melonora.

@joshua-gould are you able to check whether this fixes the issue you ran into?

This fixes my issue, thanks.

Thanks @melonora.
@joshua-gould are you able to check whether this fixes the issue you ran into?

This fixes my issue, thanks.

Great!

Thanks I’ll try to get this released next week.

Thanks @TomAugspurger !