When you module load conda/analysis3 it does not activate the environment in conda, so you can’t deactivate it. However all the packages etc in conda/analysis3 are available to use somehow (because conda “base” environment points to them?).
If I login and run module use ..., then module load ..., thenconda deactivate, the deactivate doesn’t do anything but also doesn’t give an error. I think this is because I have run conda init at some point which means a conda shell script is run when I login.
You will be able to activate your env tractive after creating it. (This will show up in the command prompt like this: (tractive) [as2285@gadi-login-04 ~]$
(Edit: Nevermind, thanks @anton, didn’t notice you had replied too, yes it looks like I have run conda init which is why it works for me)
Hi Paul, I don’t know much about these envs, but I’m just trying to duplicate the issue and it might be something specific to your environment or shell - I tried the same steps and conda deactivate and activate work with no errors.
What output do you get from which conda and which __conda_activate ?
To expand… I tried removnig my .bashrc, logged out and logged in again and was able to duplicate your issue.
I was then able to fix it by running:
module use /g/data/hh5/public/modules
module load conda/analysis3
conda init
This adds to .bashrc, so can then log out and in again, which now activates the default (base) environment, and makes conda activate and deactivate commands available, then conda activate envname will work
Not sure if this is the best approach as it sets up a fixed version of the analysis3 conda environment as the default conda. Perhaps others can weigh in if there is a better way to have conda available on login.
The second command you tried (conda create) is the correct one for your use case.
conda env create is a different thing that reads the packages to install from an environment.yaml file, it’s failed in the first example because you didn’t supply that file.
As Owen says, conda init will set up your bashrc file so that conda activate will work in future sessions. Alternatively you can source /g/data/hh5/public/apps/miniconda3/etc/profile.d/conda.sh which will do the same thing for your current session.
The best way currently for creating conda environments is to do them as singularity containers, since this avoids having an enormous numbers of inodes on the filesystem. I don’t think this is well documented anywhere, examples are Dale’s updated hh5 conda environments and my template at GitHub - ScottWales/singularity-conda-template
[pcl851@gadi-login-06 ~]$ conda init
no change /scratch/tm70/pcl851/conda/envs/tractive/condabin/conda
no change /scratch/tm70/pcl851/conda/envs/tractive/bin/conda
no change /scratch/tm70/pcl851/conda/envs/tractive/bin/conda-env
no change /scratch/tm70/pcl851/conda/envs/tractive/bin/activate
no change /scratch/tm70/pcl851/conda/envs/tractive/bin/deactivate
no change /scratch/tm70/pcl851/conda/envs/tractive/etc/profile.d/conda.sh
no change /scratch/tm70/pcl851/conda/envs/tractive/etc/fish/conf.d/conda.fish
no change /scratch/tm70/pcl851/conda/envs/tractive/shell/condabin/Conda.psm1
no change /scratch/tm70/pcl851/conda/envs/tractive/shell/condabin/conda-hook.ps1
no change /scratch/tm70/pcl851/conda/envs/tractive/lib/python3.11/site-packages/xontrib/conda.xsh
no change /scratch/tm70/pcl851/conda/envs/tractive/etc/profile.d/conda.csh
modified /home/851/pcl851/.bashrc
==> For changes to take effect, close and re-open your current shell. <==
This added the following to my ~/.bashrc:
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/scratch/tm70/pcl851/conda/envs/tractive/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/scratch/tm70/pcl851/conda/envs/tractive/etc/profile.d/conda.sh" ]; then
. "/scratch/tm70/pcl851/conda/envs/tractive/etc/profile.d/conda.sh"
else
export PATH="/scratch/tm70/pcl851/conda/envs/tractive/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<
Logging out and back in again results in:
###############################################################################
# Welcome to the NCI National Facility! #
[...]
CondaError: Run 'conda init' before 'conda activate'
[pcl851@gadi-login-08 ~]$ conda doctor
Environment Health Report for: /scratch/tm70/pcl851/conda/envs/tractive
Altered Files:
python-3.11.7-h955ad1f_0: 1
Environment listed in environments.txt file: âś…
Missing Files:
âś… There are no packages with missing files.
Make sure that conda is installed in your tractive environment (as that’s the path being sourced in bashrc, probably better to use your root conda environment).
conda list -n tractive conda
$ conda list -n tractive conda
# packages in environment at /g/data/hh5/public/apps/miniconda3:
#
# Name Version Build Channel
conda 4.13.0 py39h06a4308_0
Slightly different but if you want to avoid conda (which is apparently the recommendation on Gadi because of file duplication I think?) you can achieve a nice workflow with venv and pip. It’s more lightweight apparently, and works very well. Below are instructions for getting it working with ARE:
(all in terminal from ARE) -module load python3/3.11.0 (or whatever version)
cd to the place you want your venv
python3 -m venv
source /bin/activate
pip install jupyterlab
go to ARE instance launcher
Make sure Modules has python3/3.11.0 (same version as above)
Python or Conda virtual environment base to the root directory of your new venv (not the bin directory)
ARE should then be able to connect with a new python lab machine