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: falseMore information is available at https://www.anaconda.com/docs/tools/working-with-conda/channels#linux
Turnover procedures
When a researcher graduates or leaves the University, the following transition plan should be followed.
Notify team one month prior to leave date
Identify any files, projects, directories that need to remain in the lab
The researcher has the option to issue the
chowncommand on any files they own to another team memberBy 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
.bashrcfile 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 <<<