Incoherencies between docs in open_mfdataset and combine_by_coords and its behaviour.

[aulemahal]

PR #3877 adds nice control over the attrs of the ouput, but there are some incoherencies in the docs and the behaviour that break previously fine code.

MCVE Code Sample

import xarray as xr
out = xr.open_mfdataset('/files/with/*_conflicting_attrs.nc', combine='by_coords')

Expected Output

out having the attributes from the first file in the sorted glob list.

Problem Description

Fails with a MergeError .

In the doc of open_mfdataset it is said:

    attrs_file : str or pathlib.Path, optional
        Path of the file used to read global attributes from.
        By default global attributes are read from the first file provided,
        with wildcard matches sorted by filename.

But in the code, open_mfdataset calls combine_by_coords without specifying its combine_attrs argument, which defaults to 'no_conflicts', instead of the expected 'override' or 'drop'. The attributes are anyway managed by open_mfdataset further down, but in the case of conflicts the code never reaches that point.

Also, in the doc of combine_by_coords the wrong default is specified:

    combine_attrs : {'drop', 'identical', 'no_conflicts', 'override'},
                    default 'drop'
        String indicating how to combine attrs of the objects being merged:

        - 'drop': empty attrs on returned Dataset.
        - 'identical': all attrs must be the same on every object.
        - 'no_conflicts': attrs from all objects are combined, any that have
          the same name must also have the same value.
        - 'override': skip comparing and copy attrs from the first dataset to
          the result.

I think we expect either combine_by_coords to have 'drop' as the default or open_mfdataset to pass combine_attrs='drop'.

Versions

Output of xr.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.8.2 | packaged by conda-forge | (default, Apr 24 2020, 08:20:52)
[GCC 7.3.0]
python-bits: 64
OS: Linux
OS-release: 5.6.7-arch1-1
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: fr_CA.utf8
LOCALE: fr_CA.UTF-8
libhdf5: 1.10.6
libnetcdf: 4.7.4

xarray: 0.15.2.dev29+g7eeba59f
pandas: 1.0.3
numpy: 1.18.1
scipy: 1.4.1
netCDF4: 1.5.3
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: 1.1.1.2
nc_time_axis: 1.2.0
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: 1.3.2
dask: 2.14.0
distributed: 2.14.0
matplotlib: 3.2.1
cartopy: None
seaborn: None
numbagg: None
setuptools: 46.1.3.post20200325
pip: 20.0.2
conda: None
pytest: 5.4.1
IPython: 7.13.0
sphinx: 3.0.2

[TomNicholas]

Thanks for pointing this out @aulemahal .

I expect this should be relatively easy to correct @johnomotani ?

[johnomotani]

Yes, should be simple to correct. I have a unit test now that reproduces the error.

@pydata/xarray a question: for combine_by_coords should the default be combine_attrs="no_conflicts" (current code) or combine_attrs="drop" (current docs)?