Skip to content

Technical Details

To understand the motivation behind our decision to transition to using Miniforge along with important dates related to the transition, please see Transitioning from Anaconda to Miniforge.

The process for switching to Miniforge is different depending whether you have previously initialized Conda. So, the first step is to determine by one of the two following methods whether Conda has been initialized.

Checking for Conda Initialization

If, at some point, you executed conda init while running Anaconda or if you responded with "yes" to the question Do you wish the installer to initialize Miniconda3 by running conda init? during installation of Miniconda, your environment is likely set up so that you can use conda commands automatically in each new terminal session. Below, we provide two ways to check for this.

Run conda

In a new terminal session, try to get the version of Conda. If it has been initialized, it will print the version; if not, you will get an error.

$ conda -V
conda 24.5.0
The auto-activated base environment, indicated by the prompt: (base) [netID@vacc-login1 netID]$

If you have initialized conda at some point, the default behavior is to automatically activate the base conda environment in each new terminal session. This would typically be indicated in your command line prompt which would be prepended with the environment name in parentheses, as in:

(base) [netID@vacc-login1 netID]$

where the base environment is activated. It is possible to disable auto-activation of the base environment and still have conda initialized. Therefore, while the presence of (base) in your command prompt at each session definitively indicates that you have conda initialized, the absence of (base) in your command prompt does not rule out that you may have conda initialization configured.

Check your startup file

When conda init is run, it adds a set of lines to one of your startup files, ~/.bashrc. The following grep shows the output if the file contains this modification. If the line beginning with __conda_setup is not commented (begins with #), you have initialized Conda and are executing the steps at startup that provide conda for each session.

$ grep -A2 "^# >>> conda initialize" ~/.bashrc
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/users/x/y/myNetID/miniconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"

The path to bin/conda will be different if you are using conda provided by one of our python3.x-anaconda modules instead of a personal Miniconda installation. The path is not important, only that the line exists and is not commented out.

Additional Actions Required for Users with Conda Initialization

If either of these indicates you have initialized Conda, go to Additional steps when Conda has been initialized before proceeding.

Set up Miniforge

Use the Miniforge module

From this point forward, when creating new Conda or Python virtual environments, you should base them on Miniforge not Anaconda or Miniconda. To clear all previously loaded modules and load the Miniforge module, use

$ module purge
$ module load miniforge

Since Miniforge provides Conda, Mamba, pip and venv, you can create environments and install packages very much the same as before. See our documentation on Installing Python Libraries and Packages for more detail.

Update your ~/.condarc file

If you have an existing ~/.condarc file, some settings may not conform to Anaconda's current license terms. In particular, it may include the defaults channel, which should no longer be used on the VACC. If conda is configured to use the defaults channel it will need to be removed. If you wish to retain a copy of your original, unmodified settings prior to any configuration changes, enter the following (substituting dot-condarc with any alternate backup file name, if desired):

$ cp ~/.condarc ~/dot-condarc

Check to see if you are using the defaults channel by running the following command after loading the miniforge module:

$ conda config --show channels | grep defaults
  - defaults

If it shows - defaults in the output, then you need to remove that channel from your configuration as follows:

$ conda config --remove channels defaults

The defaults channel is an alias for a set of three Anaconda channels (main, r, and mysys2). Additionally, the anaconda channel is a mirror of the defaults channel. All of these channels are subject to Anaconda's terms of service and should not be added to the configuration file nor specifiied as a channel on the command line.

"Conda-forge" is a large community, but may not have every package you need. If you are interested in a particular package, you can find out if any channels offer it by searching on the anaconda.org website (this is not the same as anaconda.com). If you find a channel that you want conda to install packages from, you can add it to the conda configuration as follows:

$ conda config --add channels bioconda

This will put bioconda at the top of the list of channels. Channels have priority order, where the channel listed highest in the configuration has the highest priority. If you prefer the channel added to the bottom of the list of channels, you should instead use:

$ conda config --append channels bioconda

You can list all configured channels with the following command:

$ conda config --show channels
channels:
  - conda-forge
  - bioconda

NOTE: While the community-provided packages in the conda-forge channel are stored on Anaconda, Inc.'s servers, they are not owned or created by Anaconda, Inc., so they do not fall under Anaconda's licensing terms.

Check for Anaconda Repository Dependencies

To check pre-existing environments, installed using Anaconda or Miniconda, for packages that used Anaconda's restricted channel(s), you'll first need to get a list of your environments.

$ conda env list
# conda environments:
#
myenv        /users/x/y/myNetID/.conda/envs/myenv
bioenv       /users/x/y/myNetID/.conda/envs/bioenv
base         /gpfs1/sw/rh9/pkgs/miniforge/25.11.0-1

For each environment path listed (ignoring the base Miniforge environment), check where the installed packages came from:

$ conda list --explicit --prefix /users/x/y/myNetID/.conda/envs/myenv | grep anaconda.com
https://repo.anaconda.com/pkgs/main/linux-64/libgd-2.2.5-h8e06009_4.conda

If you see any packages listed from repo.anaconda.com, these fall under the Anaconda Terms of Service and may require a license for continued use. If you are using an environment that depends on "repo.anaconda.com" exclusively for instructional use, you can continue to use it. However, if you use this environment for research, it is a violation of Anaconda's terms of service unless you obtain your own license. Otherwise, in order to come into compliance, you will need to replace packages installed through the Anaconda restricted channels with packages from non-proprietary channels such as conda-forge. The best way to do this is to reinstall the environment with Miniforge. You should give the environment a new name, distinct from the original name. After confirming that the new environment is fully functional, you should remove the old environment. You may wish to save an archived copy for reference.

Reinstall Existing Conda Environment

If it is a simple environment, with a known, limited set of packages, you can recreate the environment by explicitly specifying the desired packages on the command line as described in our Conda/Mamba documentation or the official Conda documentation.

Alternatively, you can generate an environment.yml file that describes the channels and list of dependencies (including specific versions and any pip-installed packages) that produced the original environment.

$ conda env export --from-history -n environment-name > environment-name.yml

If the output environment.yml file does not provide details on package dependencies, the environment likely has not been found. In this case, you must provide the full path via the --prefix option.

$ conda env export --from-history --prefix /path/to/environment-name > environment-name.yml

Use a text editor (e.g., vim, emacs, nano) to check the environment.yml file for restricted channels (e.g., defaults). Remove any restricted channels from this file.

Recreate the environment with specifications provided by the environment.yml file, giving it a new name:

$ conda env create -f environment-name.yml -n new-environment-name

Assuming all package requirements are met by the non-restricted channels, conda will find a solution that satisfies the request, though it may not be an exact replica.

Reinstall Virtual Environments created with venv

If you created any virtual environments using venv instead of conda when using any of the Anaconda modules, these environments will have to be rebuilt using Miniforge because their Python interpreter is a symbolic link back to the Anaconda installation that was used to create that venv. Once the old Anaconda modules are removed, these virtual environments will no longer work.

If you have not followed a consistent pattern and naming convention when creating virtual environments with venv, you can try to locate them using the following find commands:

find ~ -type f -name pyvenv.cfg
find /gpfs2/scratch/$USER -type f -name pyvenv.cfg

You should either build a new venv using the Miniforge module, or create a Conda environment using the conda or mamba commands provided by the Miniforge module.

About the Package Repository used for venv Environments

Packages are installed into venv environments using pip which obtains it's packages from the Python Package Index (PyPi). Since PyPi is free for use and venv does not use conda channels, you do not need to worry about Anaconda restrictions. You must, however, re-install these environments due to the fact that venv relies upon a symbolic link to the Python interpreter that was used to create it.

Reinstall Existing venv Environment

If it is a simple environment, with a known, limited set of packages, you can recreate the venv environment by following the VACC documentation on venv or see the official Python documentation on venv.

Alternatively, you can generate a requirements.txt file from the original venv virtual environment that provides a list of installed packages and their versions. You must load a miniforge module (or use your locally installed Miniforge) and activate the existing environment, then create the requirements.txt file as below:

$ module load miniforge
$ source myenv/bin/activate
$ python -m pip freeze > requirements.txt

This will save a requirements.txt file to your current directory. To recreate the environment with Miniforge, you'll need to create a new venv environment and activate it, then install the set of packages provided by the requirements.txt file as below:

$ python -m venv my-new-env
$ source my-new-env/bin/activate
$ pip install -r requirements.txt

This process installs all the specified Python packages and their exact versions, creating a replica of the original environment's Python dependencies.


If you have any questions about the transition or problems reinstalling an environment, please open a ticket with VACC support by emailing vacchelp@uvm.edu or visit us at one of our Research Computing Virtual Café sessions.