How do I prevent Conda from activating the base environment by default? - bash

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

Related

Export miniconda2's environments to miniconda3

I used miniconda2 but I had to upgrade to miniconda3. However, how can export miniconda2's environments to miniconda3?
Thank you in advance,
UPDATE
I found here the below script:
for env in $(conda env list | cut -d" " -f1); do
if [[ ${env:0:1} == "#" ]] ; then continue; fi;
conda env export -n $env > ${env}.yml
done
It only picks up the new miniconda3 environments and not the old miniconda2 which are located in a different folder.
> ls -1 /work/miniconda2/envs/
3d-dna
abyss
afterqc
busco4
...
(base)> conda activate /work//miniconda2/envs/busco4
(busco4)>
How can I modify the above script to export from miniconda2 folder?
I'm having a hard time finding a conda YML file that's that old. There's no foolproof way that I'm aware of but here is a way that should satisfice the solution.
Note: This is for linux or mac; you can use findstr for Windows. Or PowerShell.
From your environment:
conda env export --from-history | grep -v "prefix" > your_environment_name.yml
You can view the contents with cat environment.yml. This gives you the libraries -- but not the dependencies -- and no version numbers for anything. I did that because sometimes a dependent library will get dropped for some reason or another. You may need to modify this with the new version of python you want.
I think this works better than conda env export | cut -f 1 -d '=' | grep -v ^prefix because, again, sometimes a dependency will get dropped.
From there
conda env create -f your_environment_name.yml -p /home/user/anaconda3/envs/your_environment_name
An alternative approach here is to add the previous Miniconda2 package cache (/work/miniconda2/pkgs) and environments directory (/work/miniconda2/envs) to the pkgs_dirs and envs_dirs Conda configuration settings. That way you can simply continuing having them available without having to archive and recreate. There are some details in this answer.
You may need to add back the Miniconda3 locations after this if you would like them to continue to be defaults.
Also, because you installed multiple copies of Conda, you should probably check your ~/.bashrc (and/or ~/.bash_profile) file to remove any previous sections from conda init left by the other version.

Need to understand and fix conda in linx for shell scirpt [duplicate]

I am hoping to run a simple shell script to ease the management around some conda environments. Activating conda environments via conda activate in a linux os works fine in the shell but is problematic within a shell script. Could someone point me into the right direction as to why this is happening?
Example to repeat the issue:
# default conda env
$ conda info | egrep "conda version|active environment"
active environment : base
conda version : 4.6.9
# activate new env to prove that it works
$ conda activate scratch
$ conda info | egrep "conda version|active environment"
active environment : scratch
conda version : 4.6.9
# revert back to my original conda env
$ conda activate base
$ cat shell_script.sh
#!/bin/bash
conda activate scratch
# run shell script - this will produce an error even though it succeeded above
$ ./shell_script.sh
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run
$ conda init <SHELL_NAME>
Currently supported shells are:
- bash
- fish
- tcsh
- xonsh
- zsh
- powershell
See 'conda init --help' for more information and options.
IMPORTANT: You may need to close and restart your shell after running 'conda init'.
I use 'source command' to run the shell script, it works:
source shell_script.sh
The error message is rather helpful - it's telling you that conda is not properly set up from within the subshell that your script is running in. To be able to use conda within a script, you will need to (as the error message says) run conda init bash (or whatever your shell is) first. The behaviour of conda and how it's set up depends on your conda version, but the reason for the version 4.4+ behaviour is that conda is dependent on certain environment variables that are normally set up by the conda shell itself. Most importantly, this changelog entry explains why your conda activate and deactivate commands no longer behave as you expect in versions 4.4 and above.
For more discussion of this, see the official conda issue on GitHub.
Edit: Some more research tells me that the conda init function mentioned in the error message is actually a new v4.6.0 feature that allows a quick environment setup so that you can use conda activate instead of the old source activate. However, the reason why this works is that it adds/changes several environment variables of your current shell and also makes changes to your RC file (e.g.: .bashrc), and RC file changes are never picked up in the current shell - only in newly created shells. (Unless of course you source .bashrc again). In fact, conda init --help says as much:
IMPORTANT: After running conda init, most shells will need to be closed and restarted for changes to take effect
However, you've clearly already run conda init, because you are able to use conda activate interactively. In fact, if you open up your .bashrc, you should be able to see a few lines added by conda teaching your shell where to look for conda commands. The problem with your script, though, lies in the fact that the .bashrc is not sourced by the subshell that runs shell scripts (see this answer for more info). This means that even though your non-login interactive shell sees the conda commands, your non-interactive script subshells won't - no matter how many times you call conda init.
This leads to a conjecture (I don't have conda on Linux myself, so I can't test it) that by running your script like so:
bash -i shell_script.sh
you should see conda activate work correctly. Why? -i is a bash flag that tells the shell you're starting to run in interactive mode, which means it will automatically source your .bashrc. This should be enough to enable you to use conda within your script as if you were using it normally.
Quick solution for bash: prepend the following init script into your Bash scripts.
eval "$(command conda 'shell.bash' 'hook' 2> /dev/null)"
Done.
For other shells, check the init conf of your shell, copy the following content within the shell conf and prepend it into your scripts.
# >>> conda initialize >>>
...
# <<< conda initialize <<<
You can also use
conda init --all --dry-run --verbose
to get the init script you need in your scripts.
Explanation
This is related with the introduction of conda init in conda 4.6.
Quote from conda 4.6 release log
Conda 4.4 allowed “conda activate envname”. The problem was that setting up your shell to use this new feature was not always straightforward. Conda 4.6 adds extensive initialization support so that more shells than ever before can use the new “conda activate” command. For more information, read the output from “conda init –help”
After conda init is introduced in conda 4.6, conda only expose command
conda into the PATH but not all the binaries from "base". And environment switch is unified by conda activate env-name and conda deactivate on all platforms.
But to make these new commands work, you have to do an additional initialization with conda init.
The problem is that your script file is run in a sub-shell, and conda is not initialized in this sub-shell.
References
Conda 4.6 Release
Unix shell initialization
Shell startup scripts
Using conda activate or source activate in shell scripts does not always work and can throw errors like this. An easy work around it to place source ~/miniconda3/etc/profile.d/conda.sh above any conda activate command in the script:
source ~/miniconda3/etc/profile.d/conda.sh # Or path to where your conda is
conda activate some-conda-environment
This is the solution that has worked for me and will also work if sharing scripts. This also gets around having to use conda init as on some clusters I have worked with the system is initialised but conda activate still won't work in a shell script.
if you want to use the shell script to run the other python file in the other conda env, just run the other file via the following command.
os.system('conda run -n <env_name> python <path_to_other_script>')
What is the problem with simply doing something like this in your shell:
source /opt/conda/etc/profile.d/conda.sh
(The conda init is still marked as Experimental, and thus not sure if it is a good idea to use it yet).
I also had the exact same error when trying to activate conda env from C++ or Python file. I solved it by bypassing the conda activate statement and using the absolute path of the specific conda env.
For me, I set up an environment called "testenv" using conda.
I searched all python environments using
whereis python | grep 'miniconda'
It returned a list of python environments. Then I ran my_python_file.py using the following command.
~/miniconda3/envs/testenv/bin/python3.8 my_python_file.py
You can do the same thing on windows too but looking up for python and conda python environments is a bit different.
This answer from Github worked for me (I'm using Ubuntu so it's not for Windows only):
eval "$(conda shell.bash hook)"
conda activate my_env
I just followed a similar solution like the one from hong-xu
So to run a shell command that calls the script with arguments and using a specific conda environment:
from a jupyter cell, goes like this :
p1 = <some-value>
run = f"conda run -n {<env-name>} python {<script-name>.py} \
--parameter_1={p1}"
!{run}
I didn't find any of the above scripts useful. These are fine if you want to run conda in non-interactive mode, but I'd like to run it in interactive mode. If I run:
conda activate my_environment
in a bash script it just runs in the script.
I found that creating an alias in .bashrc is all that is required to change directory to a particular project I'm working on, and set up the correct conda environment for me. So I included in .bashrc:
alias my_environment="cd ~/subdirectory/my_project && conda activate my_environment"
and then:
source ~/.bashrc
Then I can just type at the command line:
my_environment
to change to the correct project and correct environment everytime I want to work on a different project.
This answer is similar to #Lamma answer. This worked for me ->
(1) I defined several variables; the conda activate function, environments directory and environment
conda_activate=~/anaconda3/bin/activate
conda_envs_dir=~/anaconda3/envs
conda_env=<env name>
(2) I source conda activate with the environment
source ${conda_activate} ${conda_envs_dir}/${conda_env}
(3) then you can run your python script
python <path to script.py>
This bypasses the conda init requirement. my .bashrc already was initialized and sourcing the .bashrc file didn't work for me. #Lamma's answer worked for me as well as the above code.
The problem is that when you run the bash script, a new (linux) shell environment is created that was not initialized properly. If your intention is to activate a conda environment, and then run python through the script, you can properly initialize the created shell
environment as discussed in the accepted solution.
If however you want to have the conda environment active after you finish this script, then this will not work because the conda environment has changed on the new shell and you exit that shell when you finish the script. Think of this as running bash, then conda activate... then running exit to exit that bash... More details in How to execute script in the current shell on Linux?:
TL;DR:
Add the line #!/bin/bash as the first line of the script
Type the command source shell_script.sh or . shell_script.sh
Note: . in bash is equivalent to source in bash.
$ conda activate scratch
or
$ source activate scratch
#open terminal or CMD as administrator
$ cd <path Anaconda3 install>\Scripts
$ activate
$ cd ..
$ conda activate scratch

How do I update the PATH in bash_profile on OSX

I'm trying to install flutter on my Mac, in order to do so I need to add a path to the .bash_profile. But when I run the command vim .bash_profile in the terminal ,I'm met with the following message.
# The original version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.7/bin:${PATH}"
export PATH
export M2_HOME=/Applications/apache-maven-3.6.3
export PATH=$PATH:$M2_HOME/bin# added by Anaconda3 2019.10 installer
# >>> conda init >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$(CONDA_REPORT_ERRORS=false '/Users/sofie-amaliepetersen/opt/anaconda3/bin/conda' shell.bash hook 2> /dev/null)"
if [ $? -eq 0 ]; then
\eval "$__conda_setup"
else
if [ -f "/Users/sofie-amaliepetersen/opt/anaconda3/etc/profile.d/conda.sh" ]; then
. "/Users/sofie-amaliepetersen/opt/anaconda3/etc/profile.d/conda.sh"
CONDA_CHANGEPS1=false conda activate base
else
\export PATH="/Users/sofie-amaliepetersen/opt/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda init <<<
This is my first time adding a PATH, I've tried looking at setting path in terminal
But I'm not sure how it applies to my problem.
Any suggestions would be appreciated. Thanks
Something important to note, is that if you're using Catalina (Or any of the newer forms os osx) your computer won't be using the bash shell by default (Although you'll still be able to update your bash_profile, it won't work, as the computer doesn't care). You'll need to update your zshrc instead of the bash profile. (just typing zsh in your terminal should be able to switch between them, showing you a % instead of a $)
The same process as with the bash profile can be used, and the same line too. Also if you WANT the computer to use the bash profile instead you can force it, but there's no realistic functionality changes between the two in 99% of applications.
Anywhere in your .bash_profile, add this line
export PATH=$PATH:/your/new/path/to/add
This simply add /your/new/path/to/add to your existing $PATH

Using Anaconda with zsh on Catalina

The Anaconda installer added this script originally to my .bashrc or .bash_profile so I copied it over to .zshrc when I switched to zsh. I recently read I didn't need to/shouldn't have copied it over since it was meant for .bash_profile, but now that macOS is moving to use zsh anyway I'd like to know what I should do. Obviously I need to tell zsh where Anaconda is but do I need that script or can I just export the Anaconda path like export PATH=/Users/ty604/anaconda3/bin:$PATH?
Script added by Anaconda installer.
export PATH=/Users/ty604/anaconda3/bin:$PATH
# added by Anaconda3 2019.03 installer
# >>> conda init >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$(CONDA_REPORT_ERRORS=false '/Users/ty604/anaconda3/bin/conda' shell.bash hook 2> /dev/null)"
if [ $? -eq 0 ]; then
\eval "$__conda_setup"
else
if [ -f "/Users/ty604/anaconda3/etc/profile.d/conda.sh" ]; then
. "/Users/ty604/anaconda3/etc/profile.d/conda.sh"
CONDA_CHANGEPS1=false conda activate base
else
\export PATH="/Users/ty604/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda init <<<
I also have many duplicate paths in $PATH because of duplicate export commands in various shell files.
$ echo $PATH
/Users/ty604/anaconda3/bin:/Users/ty604/anaconda3/condabin:/Users/ty604/anaconda3/bin:/Users/ty604/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/usr/local/share/dotnet:/Users/ty604/flutter/bin
Files in my system
.bash_history, .bash_profile, .bashrc, .profile, .zprofile, .zsh_history, .zshrc, .zshrc.pre-oh-my-zsh
Folders in my system
.bash_sessions, .oh-my-zsh, .zsh
macOS will be using zsh moving forward and we can set zsh as the default shell in Catalina which I have done. With Catalina is it ok if I remove all traces of bash and oh-my-zsh since zsh is now the default shell? Also I am using Hyper Terminal which means I do not need oh-my-zsh any longer right?
If you are using zsh as your shell (which is up to you, since Catalina still provides bash as well), and need some settings for it, they should go into .zshrc, respectivels .zprofile. Of course you don't blindly copy everything from .bashrc over, because you need to be sure that the code is valid under Zsh too. However, the code snippet you posted, looks safe for me, i.e. it should work under both bash and zsh.
In this case, I suggest (for easier maintenance) to put initialization code common to bash and zsh into a separate file, say ~/.commonrc, and source this file in .zshrc and .bashrc. Note also that .zshrc is only read if this is an interactive shell. See the section STARTUP/SHUTDOWN FILES in the zshall man-page.
Found out via an Anaconda dev post that she was using
conda_setup="$(CONDA_REPORT_ERRORS=false '/Users/user_name/anaconda3/bin/conda' shell.zsh hook 2> /dev/null)"
Couldn't find shell.zsh hook anywhere else so hopefully this will help someone else.
I am proceeding to move all bash files outside of my system since the default macOS zsh shell is now zsh.

virtualenv name not show in zsh prompt

Recently, I give a try on oh my zsh, everything looks good till I try virtualevn and virtualenvwrapper. When I activate a virtualenv (e.g test), on normal bash, I will see the virtualenv name like:
(test)abc#abc:
But when I switched to zsh, I cannot see virtualenv name. Even though, I alr add virtualenv and virtualenvwrapper in plugins of oh my zsh. I also checked the activate file of my virtualenv, it contains:
f [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] ; then
_OLD_VIRTUAL_PS1="$PS1"
if [ "x" != x ] ; then
PS1="$PS1"
else
PS1="(`basename \"$VIRTUAL_ENV\"`) $PS1"
fi
export PS1
fi
Is it because the comparision ["x" != x] return true?
Updated:
I tried to echo $PS1 in activate file, and got this:
(test) %{$fg[magenta]%}%n%{$reset_color%}%{$fg[cyan]%}#%{$reset_color%}%{$fg[yellow]%}%m%{$reset_color%}%{$fg[red]%}:%{$reset_color%}%{$fg[cyan]%}%0~%{$reset_color%}%{$fg[red]%}|%{$reset_color%}%{$fg[cyan]%}⇒%{$reset_color%}
It seems the $PS1 is correct, but when I echo $PS1 in the terminal, the (test) is gone. It seems the $PS1 is override by something else!
Do this in ~/.zshrc:
plugins=(virtualenv)
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status virtualenv)
Caveats:
1 -- add that plugin in addition to other plugins you have.
2 -- I'm using the POWERLEVEL9K theme. Maybe you theme
The best solution is to add the following to the end of your ~/.zshrc file:
export VIRTUAL_ENV_DISABLE_PROMPT=
This will override the value in virtualenv.plugin.zsh - no need to change that file.
My setting to display Python virtualenv name for the default (a.k.a. robbyrussell) theme is the following.
In the .zshrc file
virtualenv added in plugins
Add custom function:
function virtualenv_info {
[ $VIRTUAL_ENV ] && echo '('`basename $VIRTUAL_ENV`') '
}
Navigate to your theme
My theme is the default theme for zsh:
$ vim ~/.oh-my-zsh/themes/robbyrussell.zsh-theme
Add this command right after existing PROMPT commands:
PROMPT+='%{$fg[green]%}$(virtualenv_info)%{$reset_color%}%'
Finally
$ source ~/.zshrc
PS: You can add your name or a few space before or after the PROMPT+.
Hope that helps!
Found the problem, it's due to the theme. The theme I used in the above case is pygmalion, it won't allow u to change $PS1.
After changed to robbyrussell theme, I can change $PS1 in terminal, but still cannot see the virtualenv name. After a while debugging, I found that by default the virtualenv plugin of oh my zsh disable the prompt:
# disables prompt mangling in virtual_env/bin/activate
export VIRTUAL_ENV_DISABLE_PROMPT=1
So just comment out the line in virtualenv plugin, problem solved.
As per this guide here
First add virtualenv dependency under plugin in file .zshrc
If this doesn't work for you, then it means that the theme(one of oh-my-zsh theme) you have selected doesn't include virtualenv name in bash prompt so try second step.
Go to file ~/.oh-my-zsh/themes/YOUR_THEME_NAME.zsh-theme and add this in base prompt
%{$fg[green]%}$(virtualenv_prompt_info)%{$reset_color%}%
NOTE: virtualenv_prompt_info is the name of function which is declared in ~/.oh-my-zsh/plugins/virtualenv/virtualenv.plugin.zsh. If your plugin file have different function name then change it accordingly.
Or you can declare your own function in ~/.zshrc file as shown in this guide
If you are using conda to start your virtual environment the envorionment variable will be different. To figure out the name of the environment that holds your virtaulenv name type printenv and look through the output. For me it is CONDA_PROMPT_MODIFIER
after you know the name of the variable open .zshrc and add this function
function virtualenv_info {
[ $CONDA_PROMPT_MODIFIER ] && echo `basename $CONDA_PROMPT_MODIFIER`
}
and below that add this line
PROMPT="%{$fg[green]%}$(virtualenv_info)%{$reset_color%}%${PROMPT}"
close the editor and type source .zshrc
In the case you installed Anaconda using Homebrew:
brew tap homebrew/cask-versions
brew cask install anaconda
And you are using POWERLEVEL9K theme
git clone https://github.com/bhilburn/powerlevel9k.git ~/.oh-my-zsh/custom/themes/powerlevel9k
All you need to do is add this line to the end of .zshrc :
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status root_indicator background_jobs history time anaconda)
There's no need for virtualenv plugin.
Edited:
In case you already had conda installed for bash and you get:
zsh: command not found: conda
Run this:
~/anaconda3/bin/conda init zsh
I made it work following this link: https://askubuntu.com/a/387098
I reproduce the answer below.
How the prompt is changed is defined in the script bin/activate inside the virtual environment directory. This file is created by virtualenv from a template. Unfortunatelly, the only way of prompt modification provided by the template is prepending (env name) or whatever is set with --prompt.
To modify the prompt in the way you want, I'd suggest circumventing the setting of the prompt in bin/activate and modify the definition of PROMPT in your theme file.
First add the following to your.zsh-theme (or .zshrc)
export VIRTUAL_ENV_DISABLE_PROMPT=yes
function virtenv_indicator {
if [[ -z $VIRTUAL_ENV ]] then
psvar[1]=''
else
psvar[1]=${VIRTUAL_ENV##*/}
fi
}
add-zsh-hook precmd virtenv_indicator
and add %(1V.(%1v).) in front of the second line of the definition of PROMPT. It should then look like this:
PROMPT='
%(1V.(%1v).)%{$fg_bold[grey]%}[%{$reset_color%}%{$fg_bold[${host_color}]%}%n#%m%{$reset_color%}%{$fg_bold[grey]%}]%{$reset_color%} %{$fg_bold[blue]%}%10c%{$reset_color%} $(git_prompt_info) $(git_remote_status)
%{$fg_bold[cyan]%}❯%{$reset_color%} '
If you want some color you could add %(1V.%{$fs_bold[yellow]%}(%1v)%{$reset_color%}.) for example.
Explanation:
virtenv_indicator will be called each time before the prompt is created. It checks if $VIRTUAL_ENV is set and not empty. If so, it sets the first element of the $psvar array to $VIRTUAL_ENV with everything before and including the last / removed (like basename $VIRTUAL_ENV but less expensive)
In the definition of PROMPT %(1V.(%1v).) checks if the first element of $psvar is set and not empty (%(1V.true-text.false-text)) and adds the content of the this element plus some parentheses ((%1v))
export VIRTUAL_ENV_DISABLE_PROMPT=yes disables any prompt setting by bin/activate scripts.
if you use zsh and pyenv, put this into ~/.zshrc
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
#export PS1='($(pyenv version-name)) '$PS1
export PYENV_VIRTUALENV_DISABLE_PROMPT=1
export BASE_PROMPT=$PS1
function updatePrompt {
if [[ "$(pyenv version-name)" != "system" ]]; then
# the next line should be double quote; single quote would not work for me
export PS1="($(pyenv version-name)) "$BASE_PROMPT
else
export PS1=$BASE_PROMPT
fi
}
export PROMPT_COMMAND='updatePrompt'
precmd() { eval '$PROMPT_COMMAND' } # this line is necessary for zsh
I am also using Oh My Zsh with the pygmalion theme. I had to edit the pygmalion script to add the virtual environment name before the prompt name.
open ~/.oh-my-zsh/themes/pygmalion.zsh-theme, modify the prompt_pygmalion_precmd function as following:
prompt_pygmalion_precmd(){
setopt localoptions extendedglob
local gitinfo=$(git_prompt_info)
local gitinfo_nocolor=${gitinfo//\%\{[^\}]##\}}
local exp_nocolor="$(print -P \"$base_prompt_nocolor$gitinfo_nocolor$post_prompt_nocolor\")"
local prompt_length=${#exp_nocolor}
local python_venv="($(echo $CONDA_DEFAULT_ENV)) "
PROMPT="${python_venv}${base_prompt}${gitinfo}${post_prompt}"
}
The following steps should solve the problem:
open ~/.p10k.zsh.
If you use only the left prompt, make the following changes:
typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(
# =========================[ Line #1 ]=========================
os_icon # os identifier
dir # current directory
vcs # git status
# =========================[ Line #2 ]=========================
newline # \n
prompt_char # prompt symbol
virtualenv venv .venv env # show the venv on the second line
)
Add the following line, preferably after you adjust POWERLEVEL9K_VIRTUALENV_SHOW_WITH_PYENV:
typeset -g POWERLEVEL9K_VIRTUALENV_GENERIC_NAMES=()
Save the .p10k.zsh.
Restart the terminal.
Now, when you activate the virtual environment (on macOS source my_venv/bin/activate), then the name of the virtual environment (in my case, my_venv) and the version of Python installed on it (3.9.13) will appear after a beautiful Python symbol. Have a look at the attached screenshot.
I am using oh-my-zsh pygmalion them, and this works for me:
add virtualenv plugin in ~/.zshrc
open ~/.oh-my-zsh/themes/pygmalion.zsh-theme, modify the prompt_pygmalion_precmd function to this:
prompt_pygmalion_precmd(){
setopt localoptions extendedglob
local gitinfo=$(git_prompt_info)
local gitinfo_nocolor=${gitinfo//\%\{[^\}]##\}}
local exp_nocolor="$(print -P \"$base_prompt_nocolor$gitinfo_nocolor$post_prompt_nocolor\")"
local prompt_length=${#exp_nocolor}
local python_venv=$(virtualenv_prompt_info)
PROMPT="${python_venv}${base_prompt}${gitinfo}${post_prompt}"
}
Basically just add $(virtualenv_prompt_info) to your PROMPT to wherever you prefer, here I added it to the very beginning of my PROMPT.
You do not need to create new function, as per documentation - this function is created for you.
https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/virtualenv
But You still need to edit theme file, as mentioned above, just enter correct function name - virtualenv_prompt_info:
PROMPT+='%{$fg[green]%}$(virtualenv_prompt_info)%{$reset_color%}%'
After playing with the surround answers, I found the following to be the best for my use case. This checks the $VIRTUAL_ENV_PROMPT and $VIRTUAL_ENV variables every time you change directories and sets the prompt with the correct venv info.
DEFAULT_PROMPT=$PROMPT
function cd() {
builtin cd "$#"
if [[ -n "$VIRTUAL_ENV_PROMPT" ]] ; then
PROMPT="$VIRTUAL_ENV_PROMPT$DEFAULT_PROMPT"
elif [[ -n "$VIRTUAL_ENV" ]] ; then
PROMPT="(`basename $VIRTUAL_ENV`) $DEFAULT_PROMPT"
else
PROMPT=$DEFAULT_PROMPT
fi
}
export PS1='($(pyenv version-name)) '$PS1
source & link to issue #135 in pyenv-virtualenv repo:
https://github.com/pyenv/pyenv-virtualenv/issues/135#issuecomment-582180662
Back to 2023 : here something that worked for me with the theme .
Search the line for "plugins" and add virtualenv (if you are using this one)
plugins=(git python brew macos colored-man-pages virtualenv vscode)
Now look for the ZSH-Theme and use
ZSH_THEME="pygmalion-virtualenv"
Reload your terminal or kill your Visual Studio code window (reloading the terminal into VS cod didn't display the change for me...)

Resources