Switch back to (Ana)Conda

[peanutfun]

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 with conda
  • "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.

[peanutfun]

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

[emanuel-schmid]

There seems to be an issue with channel specification in Conda.

🧐 Can you add some details? who? when? where?

[elianekobler]

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: -

[peanutfun]

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?

[emanuel-schmid]

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).

[bguillod]

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.

[thomini]

@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 🥳

[peanutfun]

@thomini How did you install conda?

Could you please report the output of conda info and conda config --show-sources?

[thomini]

@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

[chahank]

Given the recent updates to conda I propose to put this switch on hold and first look at how the situation evolves.