I have a conda environment that I created with a path (conda create -p /full/path/to/env). When I activate the environment it displays the full path to the environment in parentheses at the beginning of the command prompt line. like
(full/path/to/env) [username#server]
I want to change it so it just shows env instead of full/path/to/env. How do I do that?
I tried adding the directory leading up to my conda environment (i.e. full/path/to) to my env_dirs configuration using conda config but that didn't work.
Related
I know that the following command can be used to remove one specific anaconda environment:
$ conda env remove -n env_name
But, is there any way I can specify multiple anaconda environment names in the above command line?
How can I edit the conda prompt's behavior without touching my normal prompt? I want to retain conda's prepend-to-PS1 behavior, but change the string that gets prepended.
The question how to modify conda 'source activate' ps1 behavior is very similar. However, the solution there is to either inject the conda prefix into the middle of PS1 and/or edit PROMPT_COMMAND. This breaks the encapsulation I want, and is very hacky when the prepend-to-PS1 behavior is still desirable.
My normal prompt string looks like this:
previous output
previous output
user#short-domain fullpath
$
This is the behavior I want when no conda environment is active. With a conda environment active, this becomes:
previous output
previous output
(<env-name-here>)
user#short-domain fullpath
$
I don't like how this eliminates the blank line between the previous command's output and the new prompt. Unlike the question I mentioned above, I specifically want (<env-name-here>) on its own line:
previous output
previous output
(<env-name-here>)
user#short-domain fullpath
$
Note how this means the conda prompt modification needs to include its own newline character. I could hack the other question's answers into working, but again, I don't want to touch any variables related to my normal prompt.
There is a proper and very simple way to do this using conda's native
configuration options.
Edit the .condarc file to contain the line:
env_prompt: \n({default_env})
or run the command:
$ conda config --system --set env_prompt "\n({default_env})"
Either of these will achieve the desired effect for new terminals.
Note that the --system option may not be desirable for many use cases.
See the explanation below for more details.
From the conda documentation
This feature can be elusive if you don't know where to look. The most
natural way to find it is to start with the configuration section
of the conda user guide.
The "using the .condarc conda configuration file" overview tells
us:
The conda configuration file, .condarc, is an optional runtime
configuration file that allows advanced users to configure various
aspects of conda, such as which channels it searches for packages,
proxy settings, and environment directories. For all of the conda
configuration options, see the configuration page.
The configuration page describes the setting we want, along with
its default value:
# env_prompt (str)
# Template for prompt modification based on the active environment.
# Currently supported template variables are '{prefix}', '{name}', and
# '{default_env}'. '{prefix}' is the absolute path to the active
# environment. '{name}' is the basename of the active environment
# prefix. '{default_env}' holds the value of '{name}' if the active
# environment is a conda named environment ('-n' flag), or otherwise
# holds the value of '{prefix}'. Templating uses python's str.format()
# method.
#
env_prompt: '({default_env}) '
The conda config command
The conda config command is quite useful on its own. Doing
$ conda config --describe
shows the same information as the configuration page.
Since my .condarc file is in a non-default location, I use the --system option
for conda config to prevent conda from creating a new .condarc file in my
home directory. From conda config --help:
Config File Location Selection:
Without one of these flags, the user config file at '$HOME/.condarc' is used.
--system Write to the system .condarc file at
'<my-anaconda-install-path>/.condarc'.
--env Write to the active conda environment .condarc file
(<current-env-path>). If no
environment is active, write to the user config file
($HOME/.condarc).
--file FILE Write to the given file.
I was to have a line of code at the top of my scripts that checks if a conda environment the current user exists which the contense of exactly matches a corresponding exported environment yml file. I am currently seudo doing this via :
test -d ~/miniconda3/envs/antismash_v5 || conda env create -f antismash.yml && conda activate antismash_v5 && download-antismash-databases
But this only test based on environment name and not actual packages in the environment. Is there a way to do this in shell?
I want to dynamically store in the project directory, how can I do that?
I have searching and found this Can I choose where my conda environment is stored? but this not dynamically store my conda environment to the project directory like virtualenv do
Use --prefix, -p for conda create instead of --name, -n.
$ conda create --help
...
Target Environment Specification:
-n ENVIRONMENT, --name ENVIRONMENT
Name of environment.
-p PATH, --prefix PATH
Full path to environment location (i.e. prefix).
...
Usage
conda create -p ./venv python=3.6
conda env list
# activate the local environment with relative or absolute path
conda activate ./venv
conda deactivate
# remove the env
conda env remove -p ./venv
# or just delete the "venv" folder directly
Note: When you set a specific path for your environment with -p, -n is not allowed, which means you cannot give the env a name in this case. You have to operate this kind of envs with their paths.
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.
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.
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.
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).
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