Tom Nicholas
Tom Nicholas
> What is rationale for your suggestion? My rationale is (a) convenience for the user (`pathlib` is nicer to work with than `os`) and (b) convenience for lithops developers in...
I agree - I'm constantly checking this attribute. It would be nice to also quickly see the total nbytes of the whole dataset, but I'm not sure where that would...
I'm happy to merge this @keewis ?
If I understand this correctly it basically involves the new entry point silently running completely arbitrary code at import time. This doesn't seem like a good idea to me. Our...
Rewriting the accessors to use entrypoints instead is an interesting idea... I'm still not quite sure I understand what this would look like but perhaps @dopplershift you could raise this...
> The main shortcoming in kerchunk for your files would be combining many of the reference sets into a logical aggregate dataset. Using [VirtualiZarr](https://github.com/zarr-developers/VirtualiZarr/tree/main) should make this part simpler to...
> do you think the time has come to use Vzarr to do all that MultiZarrToZarr can do? IMO it's very close. > Basically, the existing code in MZZ for...
> We may consider punting on full datatree support for zarr-v3 in this PR and fix that up in follow-on work. What exactly is the scenario/version where this doesn't work?...
That sounds fine to me!
> Edit: a complication here is that this is in open_datatree, which I think supports other backends like NetCDF too. It's not immediately clear to me whether the signature can...