Need to pin importlib-metadata for incompatibilities with esmpy/esmf

[peanutfun]

We need to pin esmpy (a dependency of xesmf) to avoid version 8.4. This version is incompatible with the latest importlib-metadata version and causes the current builds to fail on Python 3.10+.

The pin should be

# env_climada.yml
dependencies:
  - esmpy<8.4.0,>=8.6

See https://github.com/pangeo-data/xESMF/issues/374

[peanutfun]

Pinning esmpy<8.4.0,>=8.6 is not possible, because version specifiers always imply an AND relationship. We therefore have to do esmpy!=8.4.*

[emanuel-schmid]

Nice! This leaves but one problem: looks like esmpy 8.4 is the only available version for Windows 😢

[peanutfun]

According to conda-forge, v8.6 is flagged noarch, so it should work for Windows 🤔

[peanutfun]

Fixed by #133

[emanuel-schmid]

Right - it should. But, alas:

mamba install esmpy=8.6 -c conda-forge
Could not solve for environment specs
The following packages are incompatible
└─ esmpy 8.6**  is uninstallable because there are no viable options
   ├─ esmpy 8.6.0 would require
   │  └─ esmf 8.6.0.* , which does not exist (perhaps a missing channel);
   └─ esmpy 8.6.1 would require
      └─ esmf 8.6.1.* , which does not exist (perhaps a missing channel).

Summary:

• 8.4 is broken and inhibits import of climada_petals.hazard.rf_glofas for python >= 3.10,
• 8.4 is corrupted for python >= 3.9 on Windows, #127
• 8.4 is also the only available version from conda-forge for Windows.

bottom line: rf_glofas doesn't work on Windows at the moment. How should we deal with this?

[peanutfun]

Ah, the issue is esmf, not esmpy 🤦 , and the problem is known: https://github.com/conda-forge/esmf-feedstock/issues/115

Then I suggest we simply pin importlib-metadata<8.0, because this library actually causes the issue.

I found no time to investigate #127 yet, unfortunately.

[emanuel-schmid]

Good idea, but that doesn't solve the problem, Perhaps because importlib.metadata is taken from the standard library and not from the imported package. 🤷

[peanutfun]

Did you try that? importlib_metadata is a third-party package with more recent features than importlib.metadata. According to the original report and our logs, the error originates in importlib_metadata (NO dot!) v8.0 which is way ahead of importlib.metadata, see https://github.com/python/importlib_metadata?tab=readme-ov-file#compatibility.

[emanuel-schmid]

Yes I have tried: 7b7dfed and then jenkins couldn't build the environment anymore. But that was perhaps just coincidence or a typo: Now it works: 8c515a6. 🎉

[peanutfun]

I'm glad! Thanks for looking into this