Drop ESMValTool dependency?

[Peter9192]

Currently, ewatercycle depends on esmvaltool-python. This is quite a heavy package as it installs all dependencies for all (python) recipes included with esmvaltool. Also, we need to make PRs to ESMValTool to update hydrology recipes.

One possibility would be to move the hydrology recipes (and diagnostic scripts) to eWaterCycle (or its plugins, see #335), and only rely on ESMValCore to execute them. The downside of this would be that there is no longer a central place where people can find all the hydrology recipes. But to be FAIR, we believe there shouldn't be that many...

Another alternative could be to spin off ESMValTool-Hydrology into its own small package.

[Peter9192]

Install esmvalcore still cumbersome due to cartopy dependency (non installable through pip)

[BSchilperoort]

It seems that the only way ESMValCore uses cartopy is for reading shape files. See here and here.

Ideally ESMValCore would use a lighter package that doesn't depend on gdal binaries for just reading a shapefile.

Although they also use Fiona, which depends on GDAL too.

[sverhoeven]

In #365 you can now build a ESMvalTool recipe optionally with your local diagnostic script. So you no longer need to modify the ESMValTool repo to add a recipe.

The classic models (Marrmot, hype, etc.) still use diagnostic scripts that comes from the ESMValTool Python package so we still depend on that package. We could copy the diagnostic script to the eWaterCycle plugin, then we could have ESMValCore as dep and drop ESMValTool as dep.

[sverhoeven]

On further inspection at

ewatercycle/src/ewatercycle/esmvaltool/diagnostic/copier.py

Line 6 in ad99ebf

from esmvaltool.diag_scripts.shared import (

and all other diagnostics in https://github.com/ESMValGroup/ESMValTool/tree/main/esmvaltool/diag_scripts/hydrology depend on esmvaltool.diag_scripts.shared module.

I do not see a way to not depend on ESMValTool package.

So this issue can not be implemented.