Regression: 3rd party backends are not discovered with `xarray==0.20.0`

[ashwinvis]

What happened:
I am a library developer for pymech and I added a (unreleased) xarray backend following the documentation and rioxarray's implementation. This works with xarray==0.19.0, but with the xarray==0.20.0 it no longer works. Could someone clarify what has changed?

What you expected to happen:

Backends can be discovered while using xr.open_dataset(...) with or without using the engine= keyword argument.

Minimal Complete Verifiable Example:

Since pymech's xarray backend is unreleased, I will demonstrate it via rioxarray:

#test.py
from xarray.backends import plugins

print("engines =", plugins.list_engines())
plugins.get_backend("rasterio")

$ pip install xarray==0.19.0 rioxarray
$ python test.py
engines = {'rasterio': <rioxarray.xarray_plugin.RasterioBackend object at 0x7f7adca15d00>, 'store': <xarray.backends.store.StoreBackendEntrypoint object at 0x7f7adca647c0>}

$ pip install xarray==0.20.0
$ python test.py
engines = {'store': <xarray.backends.store.StoreBackendEntrypoint object at 0x7fd99138efa0>}
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/venv/lib/python3.9/site-packages/xarray/backends/plugins.py", line 164, in get_backend
    raise ValueError(
ValueError: unrecognized engine rasterio must be one of: ['store']

Anything else we need to know?:

Environment:

Output of xr.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.9.7 (default, Oct 10 2021, 15:13:22)
[GCC 11.1.0]
python-bits: 64
OS: Linux
OS-release: 5.10.75-1-lts
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: C
LOCALE: (None, None)
libhdf5: None
libnetcdf: None

xarray: 0.20.0
pandas: 1.3.4
numpy: 1.21.3
scipy: None
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: None
nc_time_axis: None
PseudoNetCDF: None
rasterio: 1.2.10
cfgrib: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
fsspec: None
cupy: None
pint: None
sparse: None
setuptools: 57.4.0
pip: 21.2.3
conda: None
pytest: None
IPython: 7.29.0
sphinx: None

[ashwinvis]

In the same example 1st party backends such as h5netcdf work with both versions.

[keewis]

thanks for the report, @ashwinvis, that's indeed a bug in the new version, specifically here:

xarray/xarray/backends/plugins.py

Lines 102 to 106 in 960010b

	entrypoints = (
	entry_point
	for entry_point in Distribution.from_name("xarray").entry_points
	if entry_point.module == "xarray.backends"
	)

The issue is that that code assumes the backends are in the "xarray" distribution, in a module called "xarray.backends". That's not true, though: the distribution for third-party backends is the third-party library, and we're actually looking for all entrypoints in the "xarray.backends" group. Thus, the code should actually be:

    entrypoints = entry_points().get("xarray.backends", ())

I've opened a PR to fix this: #5931

[tdhopper]

😅 Good catch. I was getting an error with cfgrib not recognizing kwargs, and it's this same issue.

[da-wad]

I think this might not actually be fixed... I now get a different error from xarray==0.20.1 than I did from xarray==0.20.0 : Appveyor

entrypoints seems to have two instances of my backend, and is appears to be attempting to differentiate them using an attribute called module_name ... but I can't see how to set that, or how it would be different between the duplicates...?

[kmuehlbauer]

@da-wad I have the same issues. It looks like that the call to pytestadds the package under test to the list of distributions. This results in a duplication of the entrypoints. During the switch from pkg_resources to importlib.metadata there were changes missed to apply in remove_duplicates function.

You can try to test #5959, where I hopefully fixed all issues.

[da-wad]

Nice work, @kmuehlbauer ! #5959 does fix the issue I was experiencing - thanks! Hope we get a 0.20.2 with that soon...

[kmuehlbauer]

Thanks @da-wad. We have to wait a bit until #5959 gets reviewed again. If the reviewers are happy with the current state of the PR a 0.20.2 could be released as fast as 0.20.1. 🤞