Tom Nicholas
Tom Nicholas
> all xr.Datasets available to the user suddenly had the dunder methods that made them compliant to the dataframe data API. That specific idea is a non-starter. A cursory look...
@mdsumner you're not even supposed to be using `open_virtual_mfdataset` yet - I haven't documented it or released a version which includes it! 🤣 That said this _should_ work. This is...
Was this resolved @mdsumner ?
> virtualizarr being strict on equality. ... When Dask serialized the codecs Yeah comparing these objects has caused problems before. I am not surprised there are further edge cases, or...
> in practice they are the same codec. I don't think it's reasonable to expect VirtualiZarr to be able to deduce this. I still don't understand what you mean by...
> that would be a good place to improve this. But this is not urgent. I think that's the _only_ place we want to improve this. The current behaviour (raising...
> the dream will be to have these variable encoding datasets be zarr compatible out of the box. Wasn't there a proposal for this? https://github.com/zarr-developers/zarr-specs/issues/288 > if this gets accepted/merged,...
> In this case you would probably want to compare the JSON objects they generate to check if they are the "same" codec (from a metadata POV). What I was...
Dask uses (cloud)pickle - maybe your minimal reproducer needs to pickle then unpickle the class before comparing?
Nice! So you basically hit the same problem with dask that I had hit with lithops (as both send functions via pickle). That was the context of that PR. I'm...