Switch back to (Ana)Conda
peanutfun opened this issue ยท 10 comments
Is your feature request related to a problem? Please describe.
Installing Miniforge and Mamba (as we recommend now) is error-prone for inexperienced users. Since Conda switched to the libmamba solver, we should be able to use (Ana)conda without performance issues.
Describe the solution you'd like
-
Update the installation instructions:
- Recommend installing Anaconda or Miniconda: https://docs.anaconda.com/distro-or-miniconda/ is a suitable landing page
- Replace all
mamba
commands withconda
- "Invert" the Conda as alternative to Mamba section
- Check how the terminals of Anaconda/Miniconda are called on Windows ("Anaconda Prompt"?)
- Maybe update Glossary section
-
Update the README installation instructions
-
Update the getting started guide (recommends Mamba)
-
Try following the new instructions once with a fresh Conda distribution.
There seems to be an issue with channel specification in Conda. Even with nodefaults
specified in our environment specs, Conda still adds the defaults
channel. This can be changed by setting
default_channels: []
in the .condarc
, but this is a rather involved procedure for inexperienced users. I am still trying to figure out if this is a (unreported) bug. There are a lot of issues with environment configuration in general, see conda/conda#12355
There seems to be an issue with channel specification in Conda.
๐ง Can you add some details? who? when? where?
I installed climada_python using anaconda without problems but during the climada_petals installation ( conda env update -n climada_env -f requirements/env_climada.yml) the environment coulden't be solved. It was running for over one hour. I use a mac book air from the wcr group which I got yesterday.
I tried both:
conda config --env --add channels nodefaults
conda config --env --remove channels defaults
The defaults channel was removed in the config file but during the env update the defaults channel appears again:
(base) ekobler@usys-cx-dock-11-100 climada_petals % conda env update -n climada_env -f requirements/env_climada.yml
Channels:
- conda-forge
- defaults
Platform: osx-64
Collecting package metadata (repodata.json): done
Solving environment: -
I have been using the latest Miniconda on Euler and did not run into issues. defaults
was not added magically. Maybe this is related to @elianekobler using Anaconda?
Maybe this is related to @elianekobler using Anaconda?
That wouldn't surprise me.
Judging from the logs on Jenkins, miniconda + conda install -n base mamba -c conda-forge
does same though. It also includes the defaults
channel without being asked for. For a long time this was fine, but when I updated the conda
and mamba
packages a couple of weeks ago it started to be a problem. Afterwards any build took forever (>>1h)! I switched to miniforge3/micromamba and the build times got back to normal (and that defaults
channel nonsense stopped too).
Could this be related to conda/conda#12010, i.e. happen in cases when the defaults channel is part of the base environment? Just speculating here.
@peanutfun i have been testing to install climada using conda:
conda create -n climada_5.0 -c conda-forge climada
conda activate climada_5.0
python -m unittest climada.engine.test.test_impact
...
----------------------------------------------------------------------
Ran 41 tests in 9.772s
OK
Besides a lot of warnings in the last step, the installation was successful ๐ฅณ
@thomini How did you install conda?
Could you please report the output of conda info
and conda config --show-sources
?
@peanutfun conda was already installed on the machine I am working on, so unfortunately I can not tell you. Is the follwing output useful for you, or should I ask my admins?
And sure:
conda info
:
active environment : climada_5.0
active env location : /perm/klifol/citsys/miniconda3/envs/climada_5.0
shell level : 2
user config file : /export/home/klidl/dimgrueth/.condarc
populated config files : /export/home/klidl/dimgrueth/.condarc
conda version : 24.3.0
conda-build version : not installed
python version : 3.11.4.final.0
solver : libmamba (default)
virtual packages : __archspec=1=cascadelake
__conda=24.3.0=0
__glibc=2.31=0
__linux=5.4.0=0
__unix=0=0
base environment : /perm/klifol/citsys/miniconda3 (read only)
conda av data dir : /perm/klifol/citsys/miniconda3/etc/conda
conda av metadata url : None
channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
https://repo.anaconda.com/pkgs/main/noarch
https://repo.anaconda.com/pkgs/r/linux-64
https://repo.anaconda.com/pkgs/r/noarch
package cache : /perm/klifol/citsys/.conda/pkgs
envs directories : /perm/klifol/citsys/.conda/envs
/export/home/klidl/dimgrueth/.conda/envs
/perm/klifol/citsys/miniconda3/envs
platform : linux-64
user-agent : conda/24.3.0 requests/2.31.0 CPython/3.11.4 Linux/5.4.0-189-generic ubuntu/20.04.6 glibc/2.31 solver/libmamba conda-libmamba-solver/23.12.0 libmambapy/1.5.3
UID:GID : 44586:12305
netrc file : None
offline mode : False
conda config --show-sources
:
==> /export/home/klidl/dimgrueth/.condarc <==
envs_dirs:
- /perm/klifol/citsys/.conda/envs
pkgs_dirs:
- /perm/klifol/citsys/.conda/pkgs
Given the recent updates to conda I propose to put this switch on hold and first look at how the situation evolves.