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-1076810559,https://api.github.com/repos/pydata/xarray/issues/6374,1076810559,IC_kwDOAMm_X85ALtM_,1197350,2022-03-23T20:54:39Z,2022-03-23T20:54:39Z,MEMBER,"Sure, to be clear, my hesitancy is mostly just around being reluctant to maintain more complexity in our zarr interface. If there is momentum to implement and maintain this compatibility, I am definitely not opposed. 🚀 ","{""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-1076622767,https://api.github.com/repos/pydata/xarray/issues/6374,1076622767,IC_kwDOAMm_X85AK_Wv,1197350,2022-03-23T17:39:57Z,2022-03-23T17:39:57Z,MEMBER,"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.

Supporting nczarr directly would require lots of custom logic within xarray. That's because nczarr introduces several additional metadata files that are not part of the zarr spec. These additional metadata files break the abstractions through which xarray interacts with zarr; working around this requires going under the hood, access the store object directly (rather than the zarr groups and arrays).

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?_ If there are significant performance benefits, I would be more likely to consider it worthwhile.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856