Closed tomvothecoder closed 3 months ago
@tomvothecoder The same error just occurred to me with the v0.6.1. What would be the solution? Should we consider xesmf as an optional dependency?
@tomvothecoder The same error just occurred to me with the v0.6.1. What would be the solution? Should we consider xesmf as an optional dependency?
Are you running xcdat=0.6.1 on Linux/Mac? I am not getting this issue with a fresh install of xCDAT in a new environment on Mac, Linux, and my personal Windows machine. I think as long as the conda environment is activated, this file should be found.
mamba create -n xcdat_061 xcdat=0.6.1
mamba activate xcdat_061
>>> import xesmf
>>> import xcdat
>>> import os
>>> print(os.environ["ESMFMKFILE"])
'/opt/miniconda3/envs/xcdat_061/lib/esmf.mk'
Additionally, I just found out that ESMF/esmpy v8.5 and v8.6 are not released on conda-forge yet because of issues with the Windows build. They are also considering dropping the Windows support due to GCC build issues (comment). These version include a fix to automatically guess the ESMFMK
path (https://github.com/esmf-org/esmf/pull/151) if the env variable is not set, which happens if the conda env is not activated.
I think the safe bet might be to make xESMF an optional dependency again in v0.6.2+. We can also just wait to see what ESMF/esmpy devs decide to do. FYI @xCDAT/core-developers, sorry for the quick release of v0.6.1 without diving deeper to these non-obvious issues. ESMF/esmpy/xesmf has been challenging to work with on the build side of things.
As long as the conda environment with esmf/esmpy/xesmf is activated, the ESMFMKFILE
env var will be set. This issue has been around and we just haven’t come across it. Making xesmf a required dependency doesn’t really change anything.
The new behaviour in 8.4 was to depend on the env variable. The ESMpy conda package was updated so that this env var is set upon environment activation. However, there are many cases in which a conda env is used without being activated:
when used as a kernel in a jupyter lab/notebook instance when used to build documentation on ReadTheDocs when used as a kernel in some fancy IDEs (PyCharm for example)
-- Source: https://github.com/ESMValGroup/ESMValCore/issues/2001
I have tried in many ways to set that var in the RTD environment - to no avail, the problem is that RTD creates an env per doc build (the env is named either latest, or stable, or the number of the PR that triggered it) and doesn't do conda activate [env] explicitly so that variable is not set; trying to set it via the .readthedocs.yaml or conf.py conf files is like trying to talk to Captain Ahab that is currently stuck inside Moby Dick ie no control over the RTD's conda gubbins which are all under the hood. If anyone's managed to do this (specifically for the RTD case) I'd be very grateful for a workaround/fix 🍺 -- Source: https://github.com/ESMValGroup/ESMValCore/issues/2001](https://github.com/conda-forge/esmf-feedstock/issues/91#issuecomment-1505270915)
Are you running xcdat=0.6.1 on Linux/Mac? I am not getting this issue with a fresh install of xCDAT in a new environment on Mac, Linux, and my personal Windows machine. I think as long as the conda environment is activated, this file should be found.
@tomvothecoder I made a fresh env and the issue is not occurring. It might caused by some conflict from my old env, which I couldn't identify the specific conflicted one.
I am reopening this issue as I am getting this error from Nimbus jupyterhub when importing pcmdi_metrics, which is coming from xesmf underneath of xcdat.
@jasonb5 do you have any idea how to address this?
Workaround (this must be broken into two Jupyter cells if using Jupyter):
Cell one:
import os
os.environ['ESMFMKFILE'] = 'conda-envs/xcdat/lib/esmf.mk'
Cell two:
import xcdat as xc
Was this ever resolved? @lee1043
I opened this for the Nimbus jupyter hub (NOT binder hub), but as it may not xCDAT issue, I am okay to close this issue. I expect the Nimbus jupyter hub issue should be solved when the env updated. @jasonb5 could you confirm my theory?
@lee1043 – does this work (three comments up)?
If so, maybe that should be added to the docs somewhere.
This is fixed
What happened?
In xCDAT <=0.6.0,
xesmf
was an optional dependency in the codebase and package. As a result, RTD builds were successful despite not installingxesmf
.xCDAT now lists
xesmf
as a required dependency. This causes issues with the RTD build because the ESMF 'ESMFMKFILE' env variable is not being set. RTD does not activate the conda environment before running other steps in the build process, resulting in failures with RTD builds for v0.6.1+.What did you expect to happen? Are there are possible answers you came across?
I believe as long as the conda environment that has
xcdat=0.6.1
andxesmf
is activated,ESMFMKFILE
should be set. However, we can't modify the build steps for RTD since that is all handled internally. More info in this comment.For future reference, both of these workarounds resolve this issue:
.readthedocs.yaml
to set conda env variables: https://github.com/readthedocs/readthedocs.org/issues/5339#issuecomment-1576603529conf.py
to set environment variables: https://github.com/conda-forge/esmf-feedstock/issues/91#issuecomment-1387279692Minimal Complete Verifiable Example (MVCE)
No response
Relevant log output
Anything else we need to know?
Environment
xcdat=0.6.1