As of March 2024, Anaconda and Miniconda cost money to use.
It is not allowed to use any packages from the main Anaconda channels, which are the default in both Anaconda and Miniconda. Use
conda-forgechannels instead. This also implies that you cannot use a self-installed Anaconda or Miniconda. Use Miniforge or another free alternative instead.
On this page, we describe how to use Miniforge and Conda, and some pointers regarding the legal situation.
While Anaconda and Miniconda are disallowed, the actual Conda package manager is available and can be used on all our systems. We recommend to use the centrally installed Miniforge as an alternative to Anaconda. You can access it with the command:
module load Miniforge3
This is true on both Bender and Marvin. From that point you can do a conda init as normal.
The first time you use Conda, you need to perform a conda init. However, you do not need to repeat that, and do not need to put the conda init into your job scripts. During the conda init, Conda will modify your .bashrc file to add paths and other settings.
Note: By modifying your .bashrc, Conda bypasses the environment module system. This can lead to conflicts. See below for some tips for troubleshooting these problems.
From that point on, you can use conda commands to create environments and install packages as normal.
You cannot install packages into the (base) environment, as that is in a central install location where you have no access. Always create your own Conda environment.
Packages will be installed into your home directory, so keep an eye on your disk quota. The Conda user guide can be found here.
Tip: Performing a conda clean --all on occasion will delete unneeded cached files and greatly reduce the space that Conda occupies in your home directory.
No matter what method you use, make sure you install the correct variant of your package. For example,
conda installon Bender will install non-GPU variants because Conda will detect that the login node does not have a GPU. Either select the correct variant manually or do theconda installinside of an interactive job.
In the past, users have experienced problems which consisted of a complex interplay between the following factors:
/home/<username>/.bashrc fileThere is no general solution to this problem. Remember that you can use source ~/.bashrc, conda activate/conda deactivate and module load/module unload in your script to manipulate the order of environment changes, as in the following example:
!/bin/bash
#SBATCH <...>
source ~/.bashrc
conda deactivate
conda activate <environment>
<following-script>
Since Anaconda and Miniconda are disallowed on our systems, any Conda installations you have in your home must to be migrated to Miniforge or another free-to-use alternative.
You can still install your own instance in your home, as long as you are not violating any Terms of Service or licensing agreements. However we recommend to use our central Miniforge3 environment module.
For each Conda env you want to keep, do the following:
Export the package config with conda env export --from-history -n YOUR_ENV_NAME > filename.yml, where filename is something you pick. Use a new file for every env. Keep those files.
The option --from-history will ensure that only packages that you explicitly installed will be exported. All dependencies will be resolved newly when creating the new env. This is necessary because conda-forge has newer versions for some packages than defaults. It seems to affect particularly packages where it would be a security risk to not have the newest one (e.g. libssh2).
If you need specific versions of a dependent package, you might need to edit the .yml file manually or otherwise modify the env when you recreate it later in step 5.
Open the filename.yml with a text editor. Near the top, under the heading channels:, there will likely be an entry - defaults. Remove this line.
Conda documentation on exporting environments and on channels.
.bashrc fileconda deactivate.conda init --reverse..bashrc (or the .rc file of whatever console you use). This includes any module load Anaconda3 you might have.Explanation of the .bashrc file on Stack Exchange.
.conda directory with all its contents from your home.~/anaconda3, Miniconda into ~/miniconda3..condarc file you might have in your home directory. If you have made settings changes that you want to keep, rename the file and re-create it later, but make sure it does not re-enable the defaults channels.module list that all modules are unloaded (perform a module purge if you have to).module load Miniforge3.conda init.For every environment you want to restore, perform the following steps:
conda env create -n NEW_ENV_NAME -f filename.yml where the filename.yml is the corresponding file you exported earlier, and NEW_ENV_NAME is whatever you want to call the env.base environments in our tests usually failed to work, but others are likely to work.If creation of the new env failed, you might have to start with a new empty env and only install packages that you are absolutely sure you need.
In principle, yes. However that is easier than it sounds, see our migration guide.
We have installed Miniforge3 as an environment module on all our systems. Other third-party installers are Mambaforge (which is being discontinued and merged with Miniforge) and Pixi, which we have not tested and cannot say anything about.
The Conda package manager has been published under the 3-clause BSD license, which allows free redistribution.
The restrictions only apply to the act of downloading packages from the default Conda channels. The actual package contents are each under their own license. This also means that the exact same package can be downloaded freely from e.g. conda-forge if it exists there.
Not really. In our tests we have seen that the "base" environment, which gets created with every new Anaconda and Miniconda installation, contains packages from the default channels. There is no way around this, except not using Anaconda or Miniconda.
No. Unfortunately, the Miniconda installer installs some packages from the defaults channels (presumably the ones that are necessary to run Conda itself), which you or we cannot do anything against. We have tested this and found no alternative other than using a third-party installer like Miniforge.
As far as we can tell, no. The conda console command is available and works as normal, and you can do a conda init. Miniforge also includes mamba, which can be used as an optional alternative to conda.
First, we are not lawyers. Second, we cannot be sure that the Anaconda company sees it the same way. Third, it is unlikely that the Anaconda company can tell from the IP address whether an individual or a HRZ admin installed the package. This is why we have decided to disallow Anaconda on our systems. Please keep in mind that when registering for our systems you agreed to obey the HRZ Terms of Service and the HPC Terms of Service (links in German).
That is outdated information. The ToS were modified in 2020 and again in March 2024. Here is a news article from 2024 on the matter.
Update: While we were in the process of implementing the ToS changes, Conda reversed their course yet again. However the Terms of Service were not updated, and we are therefore not changing our policy either.
That question is completely separate from using Anaconda on Bender, Bonna or Marvin. The HPC Team cannot speak for the university in general, nor for HRZ services beyond HPC.