35

I'm using virtualenv, virtualenvwrapper, zsh, oh-my-zsh, terminator, on Crunchbang.

I'm trying to display the name of the current virtualenv like so

workon example
(example)... 

I've tried many solutions none seems to work, here's my .zshrc file, I know it's no big deal to fix it but I can't find the right solution. It has been a long time since the last time I used Linux for Django development, I forgot what I used to do.

Right now, I see username@crunchbang, I can't tell which virtualenv I'm using.

2
  • I believe you're asking how to set your prompt so that it shows which virtualenv you're in, correct?
    – slm
    Aug 16, 2013 at 23:54
  • @slm yes exactly
    – Lynob
    Aug 16, 2013 at 23:57

7 Answers 7

21

Shell's prompt

Inside your virtualenv environment is a file, bin/activate. You can edit this file to change your prompt to whatever you want it to look like. Specifically this section of the file:

...
else
    PS1="(`basename \"$VIRTUAL_ENV\"`)$PS1"
fi
...

The variable PS1 is a special variable that controls what a shell's prompt will look like. Changing its value will change your virtualenv prompt:

PS1="(this is my prompt) "

Example

  1. Create a sample environment.

    $ virtualenv tst-env
    
  2. When you're using virtualenv you typically source this file.

    $ cd $HOME/tst-env
    
    $ source bin/activate
    (tst-env)[saml@grinchy tst-env]$ 
    
  3. After making the above change to the variable PS1 in the bin/activate file my prompt is now this:

    $ source bin/activate
    (tst-env)
    

Here are the official instructions on how to do this.

24
  • tried it now, didn't fix it
    – Lynob
    Aug 17, 2013 at 9:10
  • here's my activate file pastebin.com/tZqdr1Yz
    – Lynob
    Aug 17, 2013 at 11:11
  • What happens when you source the activate file? Your file worked fine for me.
    – slm
    Aug 17, 2013 at 12:32
  • i see no output, so i can't tell what happens, the virtualenv is working other than that i see nothing, maybe it's .zshrc issue or virtualenvwrapper? can this issue be debugged? please note i have 2 virualenv executable files, the normal virtualenv and virtualenv-2.7 is this normal or did virtualenv got downloaded twice? and this is how i installed virtualenv and virualenvwrapper in case it matters sudo pip install virtualenv
    – Lynob
    Aug 17, 2013 at 13:02
  • @Fischer - I just double checked it using zsh and it works with that too, so this is most likely an env. issue. Let's ignore the 2 virtualenv's setups for the time being. To debug you can enable it, set -x, in your shell and then re-run the source activate command again. You should see PS1= lines where the prompt is getting set.
    – slm
    Aug 17, 2013 at 14:11
3

If you're using virtualenvwrapper and zsh there are a number of zsh hooks in your ~/.virtualenvs/ directory that you can use to customize your environments. Here is a bit of info regarding these. You can force an update to PS1 that will prepend the current working virtualenv to your shell prompt by adding:

_OLD_VIRTUAL_PS1=$PS1
PS1="(`basename \"$VIRTUAL_ENV\"`) $PS1"
builtin \export PS1

to ~/.virtualenvs/postactivate. To remove the tag when you deactivate, add:

PS1=$_OLD_VIRTUAL_PS1
builtin export PS1

to ~/.virtualenvs/postdeactivate

The only (plausible) thing that should break this is resourcing ~/.zshrc while working in a virtualenv

3
  • I believe you're postdeactivate script has a mistake. it should read PS1=$_OLD_VIRTUAL_PS1 builtin \export PS1 Feb 2, 2017 at 16:35
  • virtualenvwrapper already does this by default now. In venv created by virtualenvwrapper, the bin/activate script contains code to pre-pend the venv name to both zsh and bash prompts!
    – Erikw
    Nov 8, 2019 at 16:49
  • echo "${VIRTUAL_ENV+(${VIRTUAL_ENV##*/}) }", but yeah it's already done when sourcing the venv nowadays Apr 19, 2021 at 7:51
2

You don't have to edit your ~/.zshrc.

Since you are working with virtualenvwrapper it's possible to add options or hooks to $WORKON_HOME/post(de)activate files.

If you want to see more details consult here.

The above link allow me to do next:

In my case $WORKON_HOME=~/Envs because I modified this path when I installed virtualenvwrapper; if you didn't you should have the folder ~/.virtualenvs.

  1. Open the file postactivate located in $WORKON_HOME

  2. Add these lines:

    PS1="$_OLD_VIRTUAL_PS1"
    _OLD_RPROMPT="$RPROMPT"
    RPROMPT="%{${fg_bold[white]}%}(env: %{${fg[green]}%}`basename \"$VIRTUAL_ENV\"`%{${fg_bold[white]}%})%{${reset_color}%} $RPROMPT"
    
  3. Save and enjoy!

    You will obtain something like this: done

  4. (OPTIONAL) If you want you could edit the postdeactivate file to add this line:

    RPROMPT="$_OLD_RPROMPT"
    
1
1

If you know the theme that is being used, you can add a function to retrieve the activated VIRTUAL_ENV base name and use it in the PROMPT variable in the *.zsh-theme file located at ~/.oh-my-zsh/themes/ and that should do the trick!

For me it was the default 'oh-my-zsh' theme i.e. 'robbyrussels' which was configured.

function virtualenv_info {
    [ $VIRTUAL_ENV ] && echo '('`basename $VIRTUAL_ENV`') '
}

local ret_status="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
PROMPT='${ret_status} $(virtualenv_info) %{$fg[cyan]%}%c%{$reset_color%} $(git_prompt_info)'

Adding the above code generated the below result:

enter image description here

(kunkka.com) is the virtualenv which I just deactivated.

After editing the theme file don't forget to source the .zshrc file.

-> source ~/.zshrc
1

[While this answer arguably strays a bit from answering the question as asked (though I attempt to at least partially do that, as well), I found my way to this question when looking for an answer that I knew existed for venv (instead of virtualenv), that I couldn't remember the exact details of (namely, the --prompt option, which both commands support). I suspect I won't be the first, so here goes.]


with virtualenv / main answer:

First off, the basic answer to your core question is that you shouldn't need to do anything to get a prompt change, except to have an environment created, run its activate source file (which workon should effectively do for you), and have otherwise followed the installation docs (more below) — e.g. an extract from the virtualenv docs:

$ workon
$ mkvirtualenv mynewenv
New python executable in mynewenv/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(mynewenv)$

This sort of behavior is what I'd expect from typing workon example, as you do in the question text, above (except you'd then get a prompt of (example)$ instead of (mynewenv)$).

If you're not getting that, I'd make sure you're following all the proper steps for setting up virtualenv. It's relatively unlikely you'd need to change anything in your .zshrc [side note: your link to that is dead now] — except as per the original installation instructions, which suggest adding the following (or a lazy-loading alternative, also listed there):

export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
source /usr/local/bin/virtualenvwrapper.sh

And there should be nothing else... unless you're wanting the name to show up in a different place in your prompt or something (in which case, you may find some of the answers to this question useful).

That said, there's also a question of simply naming the environment, which can be done either by naming the folder that stores the env, e.g.:

virtualenv example

Or by specifying a prompt when creating the environment with a different name, e.g.:

virtualenv env --prompt example

(This latter would create the files in a directory called ./env, but the prompt when activating it would start with (example).)

with venv:

In modern (as I write this) python environments, it's also fairly common to just use the ships-with-python venv instead of (the pip-installed) virtualenv (though virtualenv still has adherents and reasons to use it — if I understand things correctly, venv is basically just a stripped-down version of virtualenv, with the latter having additional features and other improvements, not found in venv), and with venv, the equivalent of those last two commands (above) would be either:

python3 -m venv example

... or...

python3 -m venv env --prompt example

... respectively.

I hope this is useful (to someone)!

0

I just test it on ubuntu 14.04 and i had the same problem. To fix it add this to your .zshrc

source /usr/share/virtualenvwrapper/virtualenvwrapper.sh

or run this in terminal

echo source /usr/share/virtualenvwrapper/virtualenvwrapper.sh >> ~/.zshrc

In Mac OS X I had to do

echo source /usr/local/bin/virtualenvwrapper.sh >> ~/.zshrc
0

Edit your bin/activate file of your virtualenv from this

else
    PS1="(`basename \"$VIRTUAL_ENV\"`) ${PS1-}"
fi

To this

else
    PS1="(your prompt) ${PS1-}"
fi

By maintaining the suffix you won't lose your pwd information from the terminal

4
  • It looks like you are implicitly saying that the accepted answer is wrong.  Why are you telling the OP to switch away from that answer?  And what does ${PS1-} mean? Sep 26, 2020 at 6:47
  • I am not saying it is wrong. I am adding an improvement. With the accepted answer.. I lost my current directory info from the terminal. I was not able to edit the original comment so i added my suggestion as an asnwer And ${PS1-} is what i had in my activate file. I just copy pasted the same.
    – Vignesh Sk
    Sep 26, 2020 at 6:56
  • Well, it looks like you are saying “Get rid of the `basename \"$VIRTUAL_ENV\"` part. Sep 26, 2020 at 7:05
  • Yes.. we need to keep the suffix to save the pwd information in our terminal.. the suffix can be ${PS1-} or just $PS1 depending on the file
    – Vignesh Sk
    Sep 26, 2020 at 7:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .