pull_requests: 906521905

This data as json

id node_id number state locked title user body created_at updated_at closed_at merged_at merge_commit_sha assignee milestone draft head base author_association auto_merge repo url merged_by
906521905 PR_kwDOAMm_X842CG0x 6475 closed 0 implement Zarr v3 spec support 6528957 This is a WIP PR that is intended for use only with a development branch of Zarr (specifically https://github.com/zarr-developers/zarr-python/pull/1006). I am using it to test the [Zarr v3 spec](https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html) support that is currently being added to `zarr-python`. The primary changes needed were: - 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. - 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. The good news is that these changes are quite small overall. Most changed lines in the tests involve optionally passing `zarr_version` around so that we could test v3 support both with an explicit DirectoryStoreV3 store as well as with string-based paths. Other points that need consideration in regards to the spec - a number of the tested data types including unicode strings, byte strings, complex floats, datetime arrays and structured arrays which are not part of the core v3 spec. We currently do implement these for the v3 spec in zarr-python in the same way they worked for v2, but the implementation is subject to change based on decisions around v3 protocol extensions related to these dtypes. A very rough initial draft of such extensions is at https://github.com/zarr-developers/zarr-specs/pull/135. - `dtype=str` is used in some tests. Currently zarr-python uses a numcodecs filter [VLenUTF8](https://numcodecs.readthedocs.io/en/stable/vlen.html#numcodecs.vlen.VLenUTF8) in this case. The core zarr v3 spec no longer has a `'filter'` entry as part of the metadata. A zarr v3 protocol extension needs to be defined to specify how this should be implemented. We do support this filter even for zarr v3 arrays currently, but it is done in a hacky way that needs to be standardized. This is the cause of the `TODO` comment around the call to `attributes.pop('filters', None)`. cc @joshmoore, @rabernat, @MSanKeys963 - [ ] Closes #xxxx - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [x] New functions/methods are listed in `api.rst` 2022-04-11T21:52:37Z 2022-11-27T02:22:43Z 2022-11-27T02:22:43Z 2022-11-27T02:22:43Z 9973b6e3dba4164997749d426a06c66d7a57b87c     0 730b3ba186009e3d5343c9255953913772ea69b0 d6671dd414370d006254ba3156cb96256ce0e9c7 CONTRIBUTOR   13221727 https://github.com/pydata/xarray/pull/6475  

Links from other tables