You can set environment variables when an environment is activated by editing the activate.d/env_vars.sh script. See here: https://conda.io/docs/user-guide/tasks/manage-environments.html#macos-and-linux
The key portions from that link are:
Locate the directory for the conda environment in your Terminal window, such as
/home/jsmith/anaconda3/envs/analytics.Enter that directory and create these subdirectories and files:
cd /home/jsmith/anaconda3/envs/analytics mkdir -p ./etc/conda/activate.d mkdir -p ./etc/conda/deactivate.d touch ./etc/conda/activate.d/env_vars.sh touch ./etc/conda/deactivate.d/env_vars.shEdit
./etc/conda/activate.d/env_vars.shas follows:#!/bin/sh export MY_KEY='secret-key-value' export MY_FILE=/path/to/my/file/Edit
./etc/conda/deactivate.d/env_vars.shas follows::#!/bin/sh unset MY_KEY unset MY_FILEWhen you run
conda activate analytics, the environment variables MY_KEY and MY_FILE are set to the values you wrote into the file. When you runconda deactivate, those variables are erased.
Exactly what I was looking for. Thank you. Only small alteration since I add something to
LD_LIBRARY_PATHI cannot use unset. Instead I doexport LD_LIBRARY_PATH=${LD_LIBRARY_PATH/'PATH_I_ADDED/""}` in the deactivation scriptI've been trying to do this but the .sh files in the activate.d folder do not seem to be executing when I activate the conda environment. The new environment variables I create do not exist. Any pointers on this? Thank you!
Upvoted, useful stuff. Is there a way of doing this when creating the environment? does not seem the right thing to do with automated deployment
@E.Serra There are
pre-link,post-link, andpost-unlinkscripts that are used when a package is installed, which occurs on environment creation.Is there a good reason why this is not done automatically by conda? After all, the user of an environment is expected to be able to use mutually-dependent libraries by activating the environment. A lot of these environment-specific packages are shared libraries and python wrappers for them, so when would you NOT want to do this? Shouldn't env-specific .so files ALWAYS take precedence over other locations?