I have been trying to create a one single conda environment that would include wradlib, arm_pyart, pysteps and other related packages (shapely, scipy, cartopy and so on), but have not been able to do it as the solver keeps dying. I have an env with wradlib and pysteps on it, but it took like 20 tries with different order of installations, but maybe there is a better way to look at it? So far I have pretty much only tried creating new envs from scratch, because later installations usually fail with conda (or take 8 hours of solving and then fail).
First, is it a weird question (to have all the packages in one env)? I.e. maybe I’m just overthinking the problem…!?
Are there any pointers how to make the env creation process less painful? For example use something different than conda?
Any other good advice regarding this issue?
As long as all dependencies are somehow within conda-forge, this seems like it should work. But for some packages, carrying outdated dependencies in their conda-recipes, this might lead to unsolvable environments.
If packages need to be build from scratch or just provide wheels also could lead to version clashes along the road.
I think this was discussed already at some point at developer meetings. It would be nice, if we could somehow setup a CI run, somewhere in an openradar repo, which just verifies the installation process for our community packages.
Hey Kai!
Thanks for the comments. Seems like this is really a never ending issue, as the versions of dependencies will be upgrading and changing till the end of times.
But what I did try, is that I installed micromamba (to accompany my ancient 4.14 version conda) which worked really fast (~20 seconds) on the same command (included wradlib, pysteps and pyart) I tried last week that failed miserably with conda solver. Not that it solves the initial problem of the complex dependency tracking of all radar related packages, but having a modern package manger seems to help a lot here.