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 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.
I have a ~/.config/fish/config.fish which contains the following lines:
set PATH $PATH (go env GOPATH)/bin
set -x GOPATH (go env GOPATH)
If I simply run go env GOPATH at the command line, I get the default location (~/go):
> go env GOPATH
/Users/kurt/go
However, the $GOPATH environment variable is not defined:
> echo $GOPATH
Why is the $GOPATH environment variable not getting set?
set -x will only affect your current session. Once you logout of that session, the export will go away.
set --export --global will export your environment across all running fish sessions, however is ephemeral and will not persist after you log out.
set --export --universal will export your environment across all running fish sessions, and is persistent.
-g or --global
Causes the specified shell variable to be given a global scope.
Global variables don't disappear and are available to all functions
running in the same shell. They can even be modified.
-U or --universal
Causes the specified shell variable to be given a universal scope.
If this option is supplied, the variable will be shared between all the current
user's fish instances on the current computer, and will be preserved across
restarts of the shell
If you are running a current version of fish, you can use the built in fish_add_path (go env GOPATH)/bin once and it's done, you don't have to have it in a conf file.
To add Go paths to your Fish shell, add the following lines to your config.fish:
set -x GOPATH $HOME/go
set -x PATH $PATH $GOPATH/bin
I recently installed anaconda2 on my Mac. By default Conda is configured to activate the base environment when I open a fresh terminal session.
I want access to the Conda commands (i.e. I want the path to Conda added to my $PATH which Conda does when initialised so that's fine).
However I don't ordinarily program in python, and I don't want Conda to activate the base environment by default.
When first executing conda init from the prompt, Conda adds the following to my .bash_profile:
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/Users/geoff/anaconda2/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/Users/geoff/anaconda2/etc/profile.d/conda.sh" ]; then
. "/Users/geoff/anaconda2/etc/profile.d/conda.sh"
else
export PATH="/Users/geoff/anaconda2/bin:$PATH"
fi
# fi
unset __conda_setup
# <<< conda initialize <<<
If I comment out the whole block, then I can't activate any Conda environments.
I tried to comment out the whole block except for
export PATH="/Users/geoff/anaconda2/bin:$PATH"
But then when I started a new session and tried to activate an environment, I got this error message:
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
This question (and others like it) are helpful, but doesn't ultimately answer my question and is more suited for linux users.
To be clear, I'm not asking to remove the (base) from my $PS1 I'm asking for Conda not to activate base when I open a terminal session.
I have conda 4.6 with a similar block of code that was added by conda. In my case, there's a conda configuration setting to disable the automatic base activation:
conda config --set auto_activate_base false
The first time you run it, it'll create a .condarc in your home directory with that setting to override the default.
This wouldn't de-clutter your .bash_profile but it's a cleaner solution without manual editing that section that conda manages.
There're 3 ways to achieve this after conda 4.6. (The last method has the highest priority.)
Use sub-command conda config to change the setting.
conda config --set auto_activate_base false
In fact, the former conda config sub-command is changing configuration file .condarc. We can modify .condarc directly. Add following content into .condarc under your home directory,
# auto_activate_base (bool)
# Automatically activate the base environment during shell
# initialization. for `conda init`
auto_activate_base: false
Set environment variable CONDA_AUTO_ACTIVATE_BASE in the shell's init file. (.bashrc for bash, .zshrc for zsh)
export CONDA_AUTO_ACTIVATE_BASE=false
To convert from the condarc file-based configuration parameter name to the environment variable parameter name, make the name all uppercase and prepend CONDA_. For example, conda’s always_yes configuration parameter can be specified using a CONDA_ALWAYS_YES environment variable.
The environment settings take precedence over corresponding settings in .condarc file.
References
The Conda Configuration Engine for Power Users
Using the .condarc conda configuration file
conda config --describe
Conda 4.6 Release
The answer depends a little bit on the version of conda that you have installed. For versions of conda >= 4.4, it should be enough to deactivate the conda environment after the initialization, so add
conda deactivate
right underneath
# <<< conda initialize <<<
To disable auto activation of conda base environment in terminal:
conda config --set auto_activate_base false
To activate conda base environment:
conda activate
So in the end I found that if I commented out the Conda initialisation block like so:
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
# __conda_setup="$('/Users/geoff/anaconda2/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
# if [ $? -eq 0 ]; then
# eval "$__conda_setup"
# else
if [ -f "/Users/geoff/anaconda2/etc/profile.d/conda.sh" ]; then
. "/Users/geoff/anaconda2/etc/profile.d/conda.sh"
else
export PATH="/Users/geoff/anaconda2/bin:$PATH"
fi
# fi
# unset __conda_setup
# <<< conda initialize <<<
It works exactly how I want. That is, Conda is available to activate an environment if I want, but doesn't activate by default.
If you manage your .bashrc manually and like to keep it simple, all you really need is:
. "$HOME/anaconda2/etc/profile.d/conda.sh"
See Recommended change to enable conda in your shell.
This will make the conda command available without activating the base environment (nor reading your conda config).
Note that this is (of course) not compatible with managing the conda installation with conda init, but other than that, nothing bad is coming from it. You may even experience a significant speedup compared to the conda init generated code, because this solution avoids calling conda to parse your config files on whether to enable the base environment, etc.
It's best to also keep the if/fi lines to avoid error messages if using the same bashrc on several systems where conda may not be installed:
if [ -f "$HOME/anaconda2/etc/profile.d/conda.sh" ]; then
. "$HOME/anaconda2/etc/profile.d/conda.sh"
fi
Finally, if you share your bashrc between several systems where conda may be installed in different paths, you could do as follows:
for CONDA_PREFIX in \
"$HOME/anaconda2" \
"$HOME/miniconda3" \
"/opt/miniconda3" \
do
if [ -f "$CONDA_PREFIX/etc/profile.d/conda.sh" ]; then
. "$CONDA_PREFIX/etc/profile.d/conda.sh"
break
fi
done
Of course, this is now similar in length compared to the conda init generated code, but will still execute much faster, and will likely work better than conda init for users who synchronize their .bashrc between different systems.
for conda 4.12.0 (under WOS) the following worked (where all the previous answers -these included- didn't do the trick):
in your activate.bat file (mine was at ~/miniconda3/Scripts/activate.bat), change the line:
#REM This may work if there are spaces in anything in %*
#CALL "%~dp0..\condabin\conda.bat" activate %*
into
#REM This may work if there are spaces in anything in %*
#CALL "%~dp0..\condabin\conda.bat" deactivate
this line chage/modification doesn't work in the section (of the activate.bat file):
#if "%_args1_first%"=="+" if NOT "%_args1_last%"=="+" (
#CALL "%~dp0..\condabin\conda.bat" activate
#GOTO :End
)
maybe because it depends on how your miniconda3 (Anaconda Prompt) executable is set up: %windir%\System32\cmd.exe "/K" some-path-to\miniconda3\Scripts\activate.bat some-path-to\miniconda3 (in my case).
caveat: updating conda overwrites this (activate.bat) file; so one has to modify the above line as many times as needed/updated. not much of a deal-breaker if you ask me.
This might be a bug of the recent anaconda. What works for me:
step1: vim /anaconda/bin/activate, it shows:
#!/bin/sh
_CONDA_ROOT="/anaconda"
# Copyright (C) 2012 Anaconda, Inc
# SPDX-License-Identifier: BSD-3-Clause
\. "$_CONDA_ROOT/etc/profile.d/conda.sh" || return $?
conda activate "$#"
step2: comment out the last line: # conda activate "$#"
One thing that hasn't been pointed out, is that there is little to no difference between not having an active environment and and activating the base environment, if you just want to run applications from Conda's (Python's) scripts directory (as #DryLabRebel wants).
You can install and uninstall via conda and conda shows the base environment as active - which essentially it is:
> echo $Env:CONDA_DEFAULT_ENV
> conda env list
# conda environments:
#
base * F:\scoop\apps\miniconda3\current
> conda activate
> echo $Env:CONDA_DEFAULT_ENV
base
> conda env list
# conda environments:
#
base * F:\scoop\apps\miniconda3\current
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