How to set specific environment variables when activating conda environment?

Question

Does anyone know how to automatically set environment variables when activating an env in conda? I have tried editing */bin/activate, but that adds the new environment variables for every new env that is created. I want to set env variables that are specific to each env.

Knucklehead

There is a duplicate of this question here which provides some additional detail people may find useful in the future: #46826997 – Jonis

Answer 1

Use the files $CONDA_PREFIX/etc/conda/activate.d and $CONDA_PREFIX/etc/conda/deactivate.d, where $CONDA_PREFIX is the path to the environment.

See the section on managing environments in the official documentation for reference.

Boony

Thanks! I created the folder $PREFIX/etc/conda/activate.d, put env_vars.sh inside it and specified a some env variables in env_vars.sh. The specified env vars loaded on activation. – Knucklehead

Is there a similar solution for Windows? – Swum

@Knucklehead Thanks, that was it! See here for these instructions. – Yellowbird

for windows: check this link – Gemperle

how do you find "$PREFIX"? I tried to figure it out by looking at which python within the env, but that folder tree has no etc/ – Incautious

@DimaLituiev you may need to create the etc/conda directory. – Boony

I have the same question as @DimaLituiev, I have a directory anaconda3/etc/ but not sure if I should create conda under that directory, and if so, how I would specify the environment I want to edit activate.d for. – Jonis

For posterity, this answer covers the details related to $PREFIX very well: #46826997 – Jonis

If you're using PowerShell on Windows, you just need to create env_vars.ps1 files instead of env_vars.bat files, and, within these, set/unset the environment variables accordingly (this is currently omitted from the documentation. – Horse

Is this still valid with the current conda actvate instead of source activate? – Pork

Since a couple of days (conda 4.9) it's possible to define them in your environment.yml-file. You can find instructions in same link as given in answer. – Moazami

Answer 2

Environment Variables as Configuration Settings

Conda v4.8 introduced a new command-line interface in the conda-env tool for managing environment variables on a per-environment basis. The command is conda env config vars and here is the help description as of v4.8.3 for the command overall:

$ conda env config vars -h
usage: conda-env config vars [-h] {list,set,unset} ...

Interact with environment variables associated with Conda environments

Options:

positional arguments:
  {list,set,unset}
    list            List environment variables for a conda environment
    set             Set environment variables for a conda environment
    unset           Unset environment variables for a conda environment

optional arguments:
  -h, --help        Show this help message and exit.

examples:
    conda env config vars list -n my_env
    conda env config vars set MY_VAR=something OTHER_THING=ohhhhya
    conda env config vars unset MY_VAR

Perhaps a bit verbose, but it avoids having to manually manage files in etc/conda/(de|)activate.d.

YAML Specification

Added in Conda v4.9, there is now support for automatic defining of environment-specific variables as part of an environment YAML definition. For example,

name: foo
channels:
  - defaults
dependencies:
  - python
variables:
  MY_VAR: something
  OTHER_VAR: ohhhhya

which would set up the environment variables MY_VAR and OTHER_VAR to be set and unset on environment activation and deactivation, respectively.

Jape

This is the most up-to-date answer; the accepted answer should be this one. I personally think the YAML specification is the best way to go, as you can commit it to version control. – Homager

The documentation has more details on setting environment variables in this manner. – Adis

If the variable that I am defining is PATH, for example, how can I append to it instead of just overwriting it? – Recalcitrant

Here's the question related to my previous comment. – Recalcitrant

I had some issues with a lowercase environmental variable. A package I was using required $pandeia_refdata and it was forcing this to be capitalized. Looks like this is being worked on for future versions: github.com/conda/conda/issues/13713 – Mitchell

Answer 3

The accepted answer (conda/activate.d and conda/deactivate.d) works well enough, but it is inconvenient if you want the environment variables to be version controlled without putting the entire environment into version control too. Generally you'd want to store only the environment.yml file in version control.

(I understand that this does not apply to all projects - sometimes the entire reason for using environment variables is to prevent that particular configuration getting stored in version control.)

My preference (on Windows, but the same principle would apply on Linux) is to create a (version-controlled) activate.cmd file in the root of the project directory that sets the environemnt variable(s) and then calls conda's own activate.bat script.

Example (a per-project pylint configuration):

set PYLINTRC=%cd%\pylintrc
@activate.bat %cd%\env

Note that on Windows at least you have to set the environment variables before calling activate.bat because the call to activate.bat never returns to the calling batch file. You also have to name your own script something other than activate.bat to avoid recursion, which is why I chose the cmd extension (which is treated by Windows as a batch file in this context).

Wreak

Answer 4

So for virtualenv on Ubuntu I did the below where my virtual environement names is my_env and my environmental variables I want to persist were VAR_A and VAR_B:

virtualenv my_env
vim my_env/bin/activate

This opens the file and you can append your env variables to the end of the file like the below:

# This is me env variables to persist
export VAR_A=/home/developer/my_workspace/var_a
export VAR_B=/home/developer/my_workspace/var_b

Then exit the file.

Activate your virtualenv with

source my_env/bin/activate

Then your env variables should be good. Can verify like the below:

printenv | grep VAR_
VAR_B=/home/developer/my_workspace/var_b
VAR_A=/home/developer/my_workspace/var_a

Aspergillum

But what about unsetting the variables when deactivating? – Trophoplasm