You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Better document acceptable values for StoreLike #3303
In zarr.open, the current documentation for the store argument is:
Store or path to directory in file system or name of zip file.
It would be nice to make this more specific re. what strings are accepted, and give some examples of those strings. I think it's also possible to pass a "s3://..." fsspec string here, which isn't documented.
IMO we should asymptotically have an API that encourages the use of string URLs as much as possible. Where configuration cannot be easily expressed in a URL, we should use typeddicts like {"url": "myscheme://mypath", "anon": True}
A good solution here would be a section in the user guide that lists all acceptable forms when store is passed as a string, which could then be referenced from the API docs.
Looking into this some more, I think it's a wider issue than zarr.open alone. Many of the top level zarr functions use store (which is a zarr.storage.Storelike) as an argument, which is documented to various degrees in their docstrings For example:
zarr.open: Store or str, optional -Store or path to directory in file system or name of zip file.
zarr.create_group: Store or str - Store or path to directory in file system.
zarr.consolidate_metadata: StoreLike - The store-like object whose metadata you wish to consolidate.
zarr.open_group: Store, str, or mapping, optional - I won't copy the whole text here, but it documents e.g. dictionaries and None as additional options
...and more...
All of these pass the store to zarr.storage._common.make_store_path, so should be able to handle all the different options listed there including:
Store
StorePath
Path
None
dict[str, Buffer]
str (either fsspec url or path)
FSMap
Should I document these different options in the user guide under the implicit storage creation example? The example given there already uses an empty dict as input to zarr.create_group to implicitly create a MemoryStore (which is undocumented behaviour in the corresponding docstring). This could then be linked to from all public api functions that use StoreLike as input.
Should I document these different options in the user guide under the implicit storage creation example? The example given there already uses an empty dict as input to zarr.create_group to implicitly create a MemoryStore (which is undocumented behaviour in the corresponding docstring). This could then be linked to from all public api functions that use StoreLike as input.
This sounds like a great plan to me - especially putting all the info in one place, and then linking to it from the docstrings.
Activity
d-v-b commentedon Jul 28, 2025
IMO we should asymptotically have an API that encourages the use of string URLs as much as possible. Where configuration cannot be easily expressed in a URL, we should use typeddicts like
{"url": "myscheme://mypath", "anon": True}d-v-b commentedon Jul 28, 2025
A URL-centric API will not be possible for memory stores until we use a central registry for in-memory storage. See #2906
dstansby commentedon Aug 5, 2025
A good solution here would be a section in the user guide that lists all acceptable forms when
storeis passed as a string, which could then be referenced from the API docs.K-Meech commentedon Aug 19, 2025
I can look into adding further documentation for
storestring values 👍d-v-b commentedon Aug 19, 2025
@K-Meech that would be great! This will get even more interesting when #2943 lands
K-Meech commentedon Aug 20, 2025
Looking into this some more, I think it's a wider issue than
zarr.openalone. Many of the top levelzarrfunctions usestore(which is azarr.storage.Storelike) as an argument, which is documented to various degrees in their docstrings For example:zarr.open: Store or str, optional -Store or path to directory in file system or name of zip file.zarr.create_group: Store or str - Store or path to directory in file system.zarr.consolidate_metadata: StoreLike - The store-like object whose metadata you wish to consolidate.zarr.open_group: Store, str, or mapping, optional - I won't copy the whole text here, but it documents e.g. dictionaries and None as additional options...and more...
All of these pass the
storetozarr.storage._common.make_store_path, so should be able to handle all the different options listed there including:StoreStorePathPathdict[str, Buffer]str(either fsspec url or path)FSMapShould I document these different options in the user guide under the implicit storage creation example? The example given there already uses an empty dict as input to
zarr.create_groupto implicitly create a MemoryStore (which is undocumented behaviour in the corresponding docstring). This could then be linked to from all public api functions that useStoreLikeas input.dstansby commentedon Sep 15, 2025
This sounds like a great plan to me - especially putting all the info in one place, and then linking to it from the docstrings.