Tom Nicholas

What you're doing is correct, you should be able to use all the Xarray syntax you normally would without called anything from Cubed directly. Using the .chunk method on Xarray...

Okay so ```python > rds = ds.chunk({'time':1}, chunked_array_type="cubed") ``` You should not need to add `chunked_array_type="cubed"` here, it's supposed to automatically see that you're using cubed and assume you want...

Thanks for your patience! Cross-referencing it in a new issue on cubed-xarray could be helpful.

> Is it worth pinning xarray-cubed to and above the next release of Xarray? Yes definitely. I'm also about to suggest we rename the `ChunkManager` to `ComputeManger` to better reflect...

Turns out there is already an issue discussing something very similar (which didn't appear when I searched "kerchunk") - see https://github.com/MITgcm/xmitgcm/issues/28#issuecomment-2284292414.

> the funky compression of the LLC data is potentially a blocker. If we can make this Zarr-compatible, it should be possible. This seems like an analogous problem to https://github.com/zarr-developers/zarr-specs/issues/303...

> it feels like the long-term impact of dask is to give a small number of us a common language for these internal utilities 💯 💯 💯

There's also no `.submit()` method on lithops executors.

Another difference: lithops `wait()` is not a top-level function, it's a staticmethod on the lithops executor class, unlike `concurrent.futures.wait`.

To be more constructive, could we imagine adding a compliant executor interface to lithops, like I did here? https://github.com/zarr-developers/VirtualiZarr/pull/349#discussion_r2013060304