I noticed that the signatures of the az.InferenceData.to_netcdf() method and the az.to_netcdf() methods are not entirely aligned. For example, az.InferenceData.to_netcdf() takes a boolean compress argument which is absent in the az.to_netcdf() method. So the first request is to align these two methods so that they match.
More generally, however, there are a variety of kwargs that xarray.Dataset.to_netcdf() method accepts that are not accepted by the arviz methods. For example, there is the encoding argument that allows for much finer-grained control over the compression encoding parameters. Things might get a bit tricky when allowing a detailed specification that could, in principle, conflict with some of the arviz-provided arguments. But it might be nice to expose whatever is feasible.
I noticed that the signatures of the
az.InferenceData.to_netcdf()method and theaz.to_netcdf()methods are not entirely aligned. For example,az.InferenceData.to_netcdf()takes a booleancompressargument which is absent in theaz.to_netcdf()method. So the first request is to align these two methods so that they match.More generally, however, there are a variety of kwargs that
xarray.Dataset.to_netcdf()method accepts that are not accepted by the arviz methods. For example, there is theencodingargument that allows for much finer-grained control over the compression encoding parameters. Things might get a bit tricky when allowing a detailed specification that could, in principle, conflict with some of the arviz-provided arguments. But it might be nice to expose whatever is feasible.