Best Practices for Managing Multiple Conda Environments

Best Practices for Managing Multiple Conda Environments

Use naming conventions for conda environments

  • create date

  • target end date

  • purpose/function

  • shared versus private

    • netID should be in environment name for private environments

    • “shared” should be part of environment name for shared environments

An example is: [purpose]-[tag]-[shared|private]-[create date]-[end date]

bacphlip-analysis-shared-20250625-20260630

Documentation for Conda Environments

Some important attributes to document are:

  • Requestor

  • Requestor Email

  • Conda environment name

  • Create Date

  • Target End Date

  • Purpose

  • Software dependencies

  • Packages list (this can be a .yml file)

  • Special Instructions

  • Revision History

Removing older Conda Environments

Conda environments that are no longer needed can be removed by the research team Conda Admin.

conda remove --name [environment name] --all

The --all option removes all packages in the Conda environment. For more information, see https://www.anaconda.com/docs/tools/working-with-conda/environments#removing-an-environment

Please use the conda remove command to remove environments rather than the Linux “rm” command. This ensures that Conda packages and configurations are properly removed without impact to other active environments.

Conda Channels

A Conda channel is a location where Conda can search for packages to install new or existing environments. The recommended .condarc file for bioinformatics and analytics is:

channels: - bioconda - conda-forge - https://repo.anaconda.com/pkgs/main - defaults - https://repo.anaconda.com/pkgs/r auto_activate_base: false

Turnover procedures

When a researcher graduates or leaves the University, the following transition plan should be followed.

  1. Notify team one month prior to leave date

  2. Identify any files, projects, directories that need to remain in the lab

  3. The researcher has the option to issue the chown command on any files they own to another team member

  4. By default, ITS periodically runs a process that reassigns ownership of files of the former team member to the lab owner

Upgrading Miniconda

On an annual basis, it is recommended that the version of miniconda gets upgraded in order to stay current the latest enhancements and security patches delivered by http://Anaconda.org . If you wish to upgrade, please consult with ITS to ensure a smooth upgrade with little impact to existing environments.

Other Best Practices

  • On a semi-annual basis, the research team will meet to discuss the current Conda shared environments to identify any environments no longer in use. The team can also review documentation for the existing Conda environments

  • Updates to environments that contain tools should be copied within lab directory with a different name and with the lab member's name. Otherwise, if this is not done, updates may affect other lab members.

  • Installation of research tools such as HMMER will be done by ITS via ticket (change from existing process)

  • The .bashrc file for each team member should reference the same miniconda installation path

>>> conda initialize >>> !! Contents within this block are managed by 'conda init' !! __conda_setup="$('/network/rit/lab/andamlab/bin/miniconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)" if [ $? -eq 0 ]; then eval "$__conda_setup" else if [ -f "/network/rit/lab/andamlab/bin/miniconda3/etc/profile.d/conda.sh" ]; then . "/network/rit/lab/andamlab/bin/miniconda3/etc/profile.d/conda.sh" else export PATH="/network/rit/lab/andamlab/bin/miniconda3/bin:$PATH" fi fi unset __conda_setup <<< conda initialize <<<