• ClosesUnconstrained forwarding of backend keyword arguments #10377
• Tests added
• User visible changes (including notable bug fixes) are documented inwhats-new.rst
• New functions/methods are listed inapi.rst

This is a first attempt and base for discussion.

This PR does the following:

1. splitopen_dataset kwargs into four groups:
   Here I followed@shoyer's suggestion to use dataclassesGroup together decoding options into a single argument #4490.

• coder_opts: options for CF coders (eg. mask_and_scale, decode_times)
• open_opts: options for the backend file opener (eg. driver, clobber, diskless, format)
• backend_opts: options for xarray (eg. chunk, cache, inline_array)
• store_opts: options for the backend store (eg. group, lock, autoclose)

2. define these classes inBackendEntrypoint and override them in the subclasses.
   for now only for netcdf4/h5netcdf backends
3. implement logic intoopen_dataset
4. implement logic intoto_netcdf
5. for backwards compatibility reinitialize the above options with the given kwargs as needed

Example usage:

# simple call, use backend default optionsds=xr.open_dataset("test.nc",engine="netcdf4")# simple call# define once, use many , these should be imported from the backendopen_opts=NetCDF4OpenOptions(auto_complex=True)coder_opts=NetCDF4CoderOptions(decode_times=False,mask_and_scale=False)backend_opts=XarrayBackendOptions(chunk={"time":10})store_opts=NetCDF4StoreOptions(group="test")# engine could also be the `BackenEntryPoint`ds=xr.open_dataset("test.nc",engine="netcdf4",open_opts=open_opts,coder_opts=coder_opts,backend_opts=backend_opts,store_opts=store_opts)

CONS:

• Most users might not need to use these added options at all, but could fallback to current behaviour
• Users might complain about the additional complexity for setting up the dataclasses
• tbc.

PROS:

• strict separation of kwargs/options
• easy forwarding
• per backend kwargs/options
• easy adding kwargs/options
• tbc.

What this PR still needs to do:

• implement everything above for the other built-in backends (zarr, scipy, pydap, etc.)

I have follow-up ideas:

• implementsave_dataset inBackendEntrypoint to write to the engine's native format, liketo_netcdf would be for scipy/netcdf4/h5netcdf andto_zarr would be for zarr. With that we could do the writing with a unified API, something like:

  ds=xr.open_dataset("test.nc",engine="netcdf4")# Dataset APIds.save_dataset("test.zarr",engine="zarr)ds.save_dataset("test2.nc",engine="netcdf4")# general APIxr.save_dataset(ds,"test2.nc",engine="netcdf4")ds.save_dataset("test.grib",engine="grib")# my imaginationds.save_dataset("test.hdf5",engine="hdf5")# my imagination

• further disentangle the current built-in backends from xarray so that they could be their own module

I'm sure I have not taken into account all the possible pitfalls/problems which might arise here. I'd appreciate any comments and suggestions.