Use `micromamba` instead of `conda`

[lacava]

One other suggestion: use micromamba instead of conda (mamba is a C++ rewrite of conda - it uses the same package servers but is much faster). The docker image mambaorg/micromamba which has micromamba built-in seems to work if all conda calls are replaced with micromamba. It's much faster for me!

Originally posted by @MilesCranmer in https://github.com/cavalab/srbench/issues/59#issuecomment-1017641513

[MilesCranmer]

I think mamba can be set up in the GitHub actions with:

          use-mamba: true

in the conda-incubator action. Source: https://github.com/conda-incubator/setup-miniconda#example-10-miniforge.

Once this is done, all that needs to be done is replace all conda commands with mamba. Maybe it could even be done by setting alias conda=mamba.

Alternatively, all conda commands could be replaced by $(CONDA) and then you can define any CONDA environment variable you'd like.

[MilesCranmer]

Two other comments to get more speed:

• The test.yml should have each algorithm as part of a build matrix. That way, separate GitHub actions can test each algorithm in parallel. Thus, instead of having a 25 minute job that runs everything, you might have 15 jobs (limit is 25 jobs, so it's fine) which run in parallel for 10 minutes total. It will also be much more helpful for debugging to know immediately what algorithm broke by hovering over the actions.

e.g.,

    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        julia-version: ['1.7.1']
        python-version: ['3.9']
        os: [ubuntu-latest]
        algorithm: ['PySR', 'Operon', ....

you would then pass as an argument ${{ matrix.algorithm }} to your install.sh and test_evaluate_models.py.

• Turn back on conda caching. Not sure why it is currently turned off but it will probably help get a big speedup, especially if you are running in parallel.

[MilesCranmer]

^ My first suggestion above is now a draft PR in #65

[lacava]

The test.yml should have each algorithm as part of a build matrix.

This is now the case since PR #75 .

However, I ended up not doing the builds in parallel because it resulted in several different environments that couldn't be easily reconciled into one. I could imagine it being cleaner to have containers for each algorithm with a base image that provides the suite; but at the moment I'm not set up to run it that way on the cluster due to constraints using docker. In addition, the image is huge and needs some work to bring it down to a reasonable size before containerizing each alg.

Regarding the original point, micromamba seems to work everywhere except with PySR during the install call. So for the moment mambaforge is being used in CI and the docker build.

[folivetti]

just to add to this issue. I tried installing srbench with a fresh Anaconda install on Manjaro Linux. I've only succeeded by first changing environment.yml and specifying python=3.7 and then using mamba to create the environment.

With conda it was taking ages to figure things out.

Also, I can confirm that using mamba PySR fails to install.

[lacava]

It looks like the latest release of conda uses libmamba for resolving dependences - is that what you're using @folivetti?

On Sun, Mar 20, 2022, 4:59 PM Fabricio Olivetti de Franca < @.***> wrote:

just to add to this issue. I tried installing srbench with a fresh Anaconda install on Manjaro Linux. I've only succeeded by first changing environment.yml and specifying python=3.7 and then using mamba to create the environment.

With conda it was taking ages to figure things out.

Also, I can confirm that using mamba PySR fails to install.

— Reply to this email directly, view it on GitHub https://github.com/cavalab/srbench/issues/64#issuecomment-1073347676, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSGCGVRRXID5JUAVYAT4FLVA6GTXANCNFSM5MQJQKJA . You are receiving this because you authored the thread.Message ID: @.***>

[folivetti]

I don't think so, I had to actually install mamba

My steps:

• installed anaconda
• conda update conda
• conda env create -f environment.yml --debug
• waited for a very long time until it got stuck checking conflicts between pyarrow and a bunch of other libraries
• stopped the process and installed mamba with conda install -c conda-forge mamba
• mamba env create -f environment.yml --debug
• after a few minutes it stopped with an error indicating a conflict of python 3.9 with the other packages
• edited environment.yml to specify python 3.7
• run mamba again and then it worked

It can be the case that after specifying python 3.7 in environment.yml would also solve the problem with conda, but haven't tried that since mamba was considerably faster

[lacava]

@folivetti can you share your conda version? we can edit environment.yml to specify python 3.7.

[folivetti]

@lacava

it's conda 4.12.0

[hengzhe-zhang]

Micromamba is truly excellent; it has been a lifesaver for me!

A recent update worth noting is that Conda now officially supports libmamba. By executing the following two commands, we can utilize mamba as the solver, significantly accelerating the package installation process.

conda install -n base conda-libmamba-solver
conda config --set solver libmamba

[folivetti]

Micromamba is truly excellent; it has been a lifesaver for me!

A recent update worth noting is that Conda now officially supports libmamba. By executing the following two commands, we can utilize mamba as the solver, significantly accelerating the package installation process.

conda install -n base conda-libmamba-solver
conda config --set solver libmamba

that sounds interesting. I'll test a clean install of srbench on a machine with very restricted user rights to see if it works.

[lacava]

we're using mamba in the tests and as @hengzhe-zhang said conda now ships with the solver.