html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6374#issuecomment-1076942019,https://api.github.com/repos/pydata/xarray/issues/6374,1076942019,IC_kwDOAMm_X85AMNTD,88113,2022-03-24T00:18:14Z,2022-03-24T00:18:14Z,NONE,"> [rabernat](https://github.com/rabernat) commented [7 hours ago](https://github.com/pydata/xarray/issues/6374#issuecomment-1076622767) My opinion is that we should not try to support the nczarr conventions directly. _Xarray already supports nczarr via netCDF4_. If netCDF4 can open the Zarr store, then Xarray can read it. ... I would turn this question around and ask: _if netCDF4 supports access to these datasets directly, what's the advantage of xarray bypassing netCDF4 and opening them directly?_
@malmans2 can chime in with his experience, but it seems that from the user point-of-view, not needing to know if something is an xarray-zarr or a nczarr would be kinder of us. Plus as said below, I do think it puts us on the path to defining a common spec.
> Supporting nczarr directly would require lots of custom logic within xarray.
_Mea culpa_. I wasn't clear enough about the intent from my side at least, namely to support loading ARRAY_DIMENSIONS (or some other necessary subset) from nczarr rather than its entirety.
> [DennisHeimbigner](https://github.com/DennisHeimbigner) commented [4 hours ago](https://github.com/pydata/xarray/issues/6374#issuecomment-1076777717) `this is because xarray cannot handle subgroups.`
I'll add as a side that work on the subgroups (i.e. [datatree](https://github.com/xarray-contrib/datatree)) is progressing in case any consideration needs to be included now rather than later.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856
https://github.com/pydata/xarray/issues/6374#issuecomment-1076601482,https://api.github.com/repos/pydata/xarray/issues/6374,1076601482,IC_kwDOAMm_X85AK6KK,88113,2022-03-23T17:22:23Z,2022-03-23T17:22:23Z,NONE,"Thanks, @max-sixty! Guess it just doesn't complete for those outside the org.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856
https://github.com/pydata/xarray/issues/6374#issuecomment-1076544302,https://api.github.com/repos/pydata/xarray/issues/6374,1076544302,IC_kwDOAMm_X85AKsMu,88113,2022-03-23T16:31:53Z,2022-03-23T16:31:53Z,NONE,"Thanks for the details, @DennisHeimbigner. But my reading of what you outline is that for some nczarr datasets, xarray will be able to open them. Correct? If so, there were always likely to be follow-on's to this issue when/if we identify critical edge cases. Perhaps for the moment, though, we can focus here on what we want to enable and what can be done straight-forwardly.
That likely makes this more a question for @shoyer, @jhamman, @rabernat _et al._ (sorry, no way to `@`-mention all the current devs) @malmans2 is probably in a good place to start updating the existing Zarr backend to also check for the `nczarr` files, but if there are strong opinions against or alternatives that would be preferred, it would be good to hear about them.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856