Python/Conda

Conda is a tool for installing scientific software and keeping it in self-contained folders called environments. You will meet it most often in bioinformatics, data science and machine learning, where a great deal of software is published this way.

This page explains what Anaconda and Mamba are, why we do not recommend them on Anunna, what to use instead, and — if you have no alternative — how to use conda here with the least trouble.

Introduction

What is Anaconda

Anaconda is a Python distribution made by a company, Anaconda Inc. It arrives as one large download containing Python, the conda command and several hundred scientific packages, already installed and ready to use. It is several gigabytes in size.

It was designed for a personal computer: you install it once and nearly everything you might need is already there. That convenience is why it became so popular.

What is Mamba

Mamba is a free, open-source tool that does the same job as Anaconda's conda command. It is not a bundle — it installs only the packages you ask for, and nothing else.

Mamba comes from the conda-forge community. You normally get it by installing Miniforge, which provides both conda and mamba. It gives you access to conda-forge and to bioconda, the repository where most bioinformatics software is published.

What they have in common

Both build environments — a self-contained folder with its own Python and its own libraries. You can keep several side by side, each holding different versions of the same software, without them interfering with one another.

Both also install much more than Python packages. pip installs Python code and nothing else, whereas conda and mamba can install the things that code depends on as well: R, compilers, C libraries and command-line programs. That is the main reason people choose them.

Underneath, they are the same system. They use the same package format and the same repositories, so an environment built by one can be used by the other, and the commands are identical — create, install, activate. Moving from one to the other is not a migration; nothing needs converting.

How they differ

	Anaconda	Mamba
What you get	Python and several hundred packages, whether you wanted them or not. Several gigabytes.	Only the packages you ask for.
Where packages come from	Anaconda's own repository.	conda-forge and bioconda.
Cost	A paid licence is required for large organisations like WUR.	Free and open source.

Speed used to be a clear difference too, as mamba worked out dependencies far faster than conda did. Since conda version 23.10 the two share the same machinery for this, so the gap is much smaller than it once was.

On licensing, Anaconda changed its terms in 2024 and they may not permit research use at an institution the size of WUR — see Anaconda's own statement on academia and research.

Why they are not recommended in the cluster

Both tools do run on Anunna. Neither is a good fit for it. The reasons below apply to Anaconda and Mamba alike, except the last one.

• Neither is built for our hardware. Conda packages — from Anaconda and from conda-forge equally — are general-purpose builds that have to work on any machine in the world. The software we provide as modules is compiled for the exact processors in each generation of Anunna's nodes. If you care about speed and efficiency, use the modules in the buckets: see Python/Modules.

• They bring their own copies of software the cluster already provides. Ask for one package and you may also receive compilers, maths libraries, CUDA and MPI as dependencies. These sit alongside Anunna's own versions and can be picked up instead of them, which produces results that are hard to explain.

• Their MPI is unlikely to use Anunna's fast network. A program that spreads work across several nodes needs MPI built against the cluster's high-speed interconnect. The MPI that comes out of a conda environment is a generic build, so a multi-node job may fall back to ordinary networking and run far slower, or fail to start at all. If your work runs on more than one node, use the MPI modules.

• They assume system libraries live where they do on a laptop. Those assumptions often do not hold here, and the result is a job that fails part-way through with an error that points nowhere useful.

• They fill your home directory. A single environment is tens of thousands of small files. Your home directory is small, it is backed up, and it sits on a filesystem measured at roughly ninety times slower than Lustre for large reads and writes. See Quotas and Storage Systems Overview.

• Installing them slows the cluster down for everybody. Working out and unpacking an environment writes thousands of small files at once. On a login node, which is shared by every user, that is felt by everyone rather than only by you.

• They change your shell without asking. The conda init command writes a block into your ~/.bashrc. That block is then read again by job scripts and by interactive sessions, and it can leak into containers, causing failures that look nothing like a conda problem.

• Anaconda additionally has a BIG licensing problem. Its 2024 terms require a paid licence for organisations of 200 or more people, and the free exemption covers teaching rather than research. Other HPC centres have already stopped providing it.

What to use instead

In order — try the first before the second, and so on.

Check whether it is already a module

Most widely used scientific software is already installed on Anunna and compiled for our hardware. Search for it by name before installing anything yourself:

module key blast

module key searches every bucket at once, so you do not need to load one first. See Environment Modules.

A virtual environment on a Python module

If you only need Python packages, a virtual environment built on one of our Python modules is the right tool. It is smaller, faster and simpler than a conda environment, and it uses the Python we compiled for this machine.

Python/Modules#Virtual environments covers this in full. The one thing to remember here is that the environment belongs on Lustre — under $myNobackup — and not in your home directory.

For a faster alternative to pip when installing into such an environment, the uv module is available in the 2025 bucket, see here.

A ready-made container

Almost every package on bioconda is also published as a prebuilt container image, so you can run the software without building an environment at all. This is often the quickest route for bioinformatics software.

module load utilities Apptainer
apptainer pull https://depot.galaxyproject.org/singularity/multiqc:1.29--pyhdfd78af_0
apptainer run multiqc_1.29--pyhdfd78af_0.sif multiqc --help

Browse the image list for the tool and version you want. See Apptainer, and set APPTAINER_CACHEDIR to a location on Lustre first, as that page describes.

When none of these work

Some software is published only as a conda package and has no module, no Python-only equivalent and no container. That is a real situation, and the rest of this page is for this situation.

If you still need conda

Everything below is aimed at avoiding the issues described above. The two that matter most are keeping conda out of your ~/.bashrc and never building an environment on a login node.

Use Miniforge, not Anaconda

Miniforge is a small installer from the conda-forge community. It gives you both conda and mamba, it uses conda-forge instead of Anaconda's repository, and it carries no licence conditions.

Install it on Lustre, not in your home directory

Start an interactive session first — see below — then:

cd $myNobackup
curl -L -O https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh
bash Miniforge3-Linux-x86_64.sh -b -p $myNobackup/miniforge3

-p chooses where it goes. -b installs without asking questions and without touching your shell configuration, which is what you want.

$myNobackup is your Lustre location without backup, which is the right tier here: an environment can always be rebuilt from its list of packages, so it does not need backing up. If you have not set that variable yet, see Installing Personal Software#Aliases and local variables.

Do not let it change your shell

Never run conda init. Load conda explicitly instead, whenever you need it:

source $myNoBkp/miniforge3/etc/profile.d/conda.sh
conda activate myenv

If you have run conda init in the past, open ~/.bashrc and delete everything between the lines # >>> conda initialize >>> and # <<< conda initialize <<<, including those two lines.

Another option if you do want to keep that code block available to you is to convert it to a function in ~/.bashrc, like this:

cdi ()
{
    # >>> conda initialize >>>
< original conda initialisation code >
    # <<< conda initialize <<<
}

Then you can use cdi to load that code when in an interactive shell

Keep the package cache off your home directory

Conda keeps a cache of downloaded packages and a record of your environments. Point both at Lustre by adding these lines to your ~/.bash_aliases:

export CONDA_PKGS_DIRS=$myNoBkp/conda/pkgs
export CONDA_ENVS_DIRS=$myNoBkp/conda/envs

Never build an environment on a login node

Creating an environment is exactly the kind of work that disturbs the shared filesystem for other users. Ask for an interactive session on a compute node and do it there:

sinteractive -c 4 --mem 16G --time 120

Then create the environment. Listing the packages in a file makes it repeatable:

source $myNoBkp/miniforge3/etc/profile.d/conda.sh
mamba create -n myenv python=3.12 numpy pandas

See Interactive Jobs for the options sinteractive accepts.

Using an environment in a job script

Load conda and activate the environment inside the script itself. Note the first line: use plain #!/bin/bash, not #!/bin/bash -i, so the script does not read your shell configuration.

#!/bin/bash
#SBATCH --job-name=myjob
#SBATCH --time=1:00:00
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G

source $myNobackup/miniforge3/etc/profile.d/conda.sh
conda activate myenv

python myscript.py

See Batch Jobs.

Cleaning up

Environments are large and easy to forget. Check what you have from time to time, remove what you no longer use, and empty the download cache:

conda env list
conda env remove -n myenv
conda clean --all

See also

• Python
• Python/Modules
• Environment Modules
• Apptainer
• Interactive Jobs
• Batch Jobs
• Installing Personal Software
• Quotas

External links

• Miniforge
• conda-forge
• bioconda
• Prebuilt bioconda container images
• Anaconda's terms of service for academia and research