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/pull/6475#issuecomment-1328155507,https://api.github.com/repos/pydata/xarray/issues/6475,1328155507,IC_kwDOAMm_X85PKgtz,2448579,2022-11-27T02:22:37Z,2022-11-27T02:22:37Z,MEMBER,Thanks @grlee77 and @jhamman !,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 1, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1320701325,https://api.github.com/repos/pydata/xarray/issues/6475,1320701325,IC_kwDOAMm_X85OuE2N,2443309,2022-11-19T00:31:47Z,2022-11-19T00:31:47Z,MEMBER,This is ready to merge once https://github.com/pydata/xarray/pull/7300 is in.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1320632540,https://api.github.com/repos/pydata/xarray/issues/6475,1320632540,IC_kwDOAMm_X85Ot0Dc,2448579,2022-11-18T23:13:29Z,2022-11-18T23:13:47Z,MEMBER,"RTD failure is real.

```
/home/docs/checkouts/readthedocs.org/user_builds/xray/checkouts/6475/doc/whats-new.rst:28: WARNING: Duplicate explicit target name: ""whats-new.2022.11.1"".
```
Otherwise, is this ready to merge?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1304558730,https://api.github.com/repos/pydata/xarray/issues/6475,1304558730,IC_kwDOAMm_X85NwfyK,2443309,2022-11-05T14:38:18Z,2022-11-05T14:38:18Z,MEMBER,"@grlee77, @rabernat, @joshmoore, and others - I think this is ready to review and/or merge.  The Zarr-V3 tests are active in the `CI Upstream / upstream-dev` GitHub Action. The test failure on readthedocs is unrelated to this PR.","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 1, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1294086466,https://api.github.com/repos/pydata/xarray/issues/6475,1294086466,IC_kwDOAMm_X85NIjFC,2443309,2022-10-27T21:32:42Z,2022-10-27T21:32:42Z,MEMBER,@grlee77 - I'm curious if you are planning to return to this PR or if it would be helpful if someone brought it to completion?,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1281657040,https://api.github.com/repos/pydata/xarray/issues/6475,1281657040,IC_kwDOAMm_X85MZIjQ,2443309,2022-10-18T00:23:20Z,2022-10-18T00:23:20Z,MEMBER,"> A separate issue is that consolidated metadata isn't in the core Zarr v3 spec, so we will need to have a Zarr Enhancement Proposal to formally define how the metadata should be stored. In the experimental API, it behaves as for v2 and is stored at /meta/root/consolidated by default.

I think it would be fine to disallow consolidated metadata for v3 until there is a spec in place. This is going to be experimental for some time so I don't see the harm in raising an error when `consolidated=True` and `version=3`. I think this is better than guessing what the v3 extension will specify.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1137661171,https://api.github.com/repos/pydata/xarray/issues/6475,1137661171,IC_kwDOAMm_X85Dz1Tz,1217238,2022-05-25T18:10:21Z,2022-05-25T18:10:21Z,MEMBER,"> > One issue with relying only on `Array` and `Group` as currently implemented in Zarr-Python is that we can create array nodes outside of any group subfolder. e.g. one can currently create an Array directly at path 'array1' and this would put the chunks under `'data/root/array1/'`, and metadata at `'meta/root/array1.array.json'`. However, the root itself is not a `Group`. A group is basically a subfolder under root (e.g.' `open_group` with path = `group1` creates `'/meta/root/group1/'` folder and `'meta/root/group1.group.json'` metadata). There is no mechanism in the spec to open root directly as a `Group`!
> 
> is there an issue on the Zarr side where this is currently being discussed?

I opened up https://github.com/zarr-developers/zarr-python/issues/1039","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1099307673,https://api.github.com/repos/pydata/xarray/issues/6475,1099307673,IC_kwDOAMm_X85BhhqZ,1217238,2022-04-14T15:33:54Z,2022-04-14T15:33:54Z,MEMBER,"> One issue with relying only on `Array` and `Group` as currently implemented in Zarr-Python is that we can create array nodes outside of any group subfolder. e.g. one can currently create an Array directly at path 'array1' and this would put the chunks under `'data/root/array1/'`, and metadata at `'meta/root/array1.array.json'`. However, the root itself is not a `Group`. A group is basically a subfolder under root (e.g.' `open_group` with path = `group1` creates `'/meta/root/group1/'` folder and `'meta/root/group1.group.json'` metadata). There is no mechanism in the spec to open root directly as a `Group`!

is there an issue on the Zarr side where this is currently being discussed?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329
https://github.com/pydata/xarray/pull/6475#issuecomment-1098229361,https://api.github.com/repos/pydata/xarray/issues/6475,1098229361,IC_kwDOAMm_X85BdaZx,1217238,2022-04-13T16:04:23Z,2022-04-13T16:04:23Z,MEMBER,"> * The v3 spec **requires** a path be specified when calling `open_group` or `open_consolidated`. This PR currently just sets a default group name of `'xarray'` if one is not specified via the `group` kwarg to `ZarrStore.open_group`. I think that is convenient, but one could instead be stricter and raise an error in this case.

Does Zarr v3 have a notion of a ""root"" group? That feels like a more sensible default to me, both for Xarray and Zarr-Python

> * If a string corresponding to a filesystem path or URL is used for `store`, then it is not possible to infer which version of the zarr spec is desired. In this case, the user must specify `zarr_version` to choose the zarr protocol version. The default of `zarr_version=None` will infer the version from a zarr `BaseStore` subclass when possible, otherwise defaulting to `zarr_version=2` for backwards compatibility.

This sounds fine for now, but I am concerned that it will slow the adoption of Zarr v3. Eventually, we would presumably want to change the default to version 3, but this is difficult to do if it entirely breaks backwards compatibility.

My preference would be for the default behavior to try opening Zarr v2, and fall back to opening in v3 mode, even if this requires attempting to open a file from the store. This is similar to how Xarray handles other Zarr versioning issues (e.g., for consolidated metadata). Perhaps Zarr-Python could raise an informative error that we could catch if the Zarr version is incorrect, or even handle this behavior itself?","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1200581329