failing CI

[keewis]

It seems cfgrib (or one of its dependencies) is breaking the import of xarray on both upsteam-dev and some of the normal CI. Interestingly, the broken environments installed eccodes=2.19.1 while the ones which are passing have eccodes=2.21.0.

Is this a mamba / conda caching issue?

cc @andersy005 @alexamici

[alexamici]

Looking into ecmwf/cfgrib#226 that seems related.

[keewis]

it is interesting that this only happens for py37 macos, py37 ubuntu and py39 ubuntu but nothing else.

Looking into ecmwf/cfgrib#226 that seems related.

That does indeed seem related but seems to use py38 which does not fail for us.

For reference, this is the traceback:

traceback

 Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/runner/work/xarray/xarray/xarray/__init__.py", line 3, in <module>
    from . import testing, tutorial, ufuncs
  File "/home/runner/work/xarray/xarray/xarray/tutorial.py", line 13, in <module>
    from .backends.api import open_dataset as _open_dataset
  File "/home/runner/work/xarray/xarray/xarray/backends/__init__.py", line 6, in <module>
    from .cfgrib_ import CfGribDataStore
  File "/home/runner/work/xarray/xarray/xarray/backends/cfgrib_.py", line 19, in <module>
    import cfgrib
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/cfgrib/__init__.py", line 19, in <module>
    from .cfmessage import CfMessage
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/cfgrib/cfmessage.py", line 29, in <module>
    from . import messages
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/cfgrib/messages.py", line 28, in <module>
    import eccodes  # type: ignore
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/eccodes/__init__.py", line 15, in <module>
    from .eccodes import *
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/eccodes/eccodes.py", line 12, in <module>
    from gribapi import __version__
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/gribapi/__init__.py", line 13, in <module>
    from .gribapi import *  # noqa
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/gribapi/gribapi.py", line 32, in <module>
    from .bindings import ENC, ffi, lib
  File "/usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/gribapi/bindings.py", line 29, in <module>
    from ._bindings import ffi, lib
ImportError: /usr/share/miniconda/envs/xarray-tests/lib/python3.9/site-packages/gribapi/_bindings.cpython-39-x86_64-linux-gnu.so: undefined symbol: codes_bufr_key_is_header

[alexamici]

Thanks @keewis! ATM the main suspect is a flaky the dependency between python-eccodes and eccodes, not cfgrib itself. So it may look like a random error in CI.

[alexamici]

As a general measure I would add ImportError to the exception caught on import so we avoid to crash xarray:

xarray/xarray/backends/cfgrib_.py

Lines 18 to 29 in 186c2ff

	try:
	import cfgrib
	has_cfgrib = True
	except ModuleNotFoundError:
	has_cfgrib = False
	# cfgrib throws a RuntimeError if eccodes is not installed
	except RuntimeError:
	warnings.warn(
	"Failed to load cfgrib - most likely eccodes is missing. Try `import cfgrib` to get the error message"
	)
	has_cfgrib = False

To work around the current problem we may need to add a eccodes>=2.21.0 to the CI :/

[keewis]

To work around the current problem we may need to add a eccodes>=2.21.0 to the CI

agreed. If eccodes<2.21.0 is truly incompatible with the new version of cfgrib, you could also release a new build on conda-forge.

[alexamici]

Technically this is an incompatibility between python-eccodes and eccodes, I'm trying to resolve it via a PR to the python-eccodes-feedstock: conda-forge/python-eccodes-feedstock#71

[alexamici]

@keewis after merging #5139 the CI should not be failing anymore. The problem is now that cfgrib may not be consistently tested on all jobs and failures are silent.

I'll wait a bit for the fix in python-eccodes, otherwise I'll do a new release of the conda package of cfgrib.

[keewis]

great. If this is nothing we have control over, should we close this?

[alexamici]

Yes, I would close the issue.

[keewis]

thanks, @alexamici