virtualenvwrapper postactivate and screen is a wonderful combination

I switched to virtualenvwrapper from plain old virtualenv a while back because I found out that virtualenvwrapper has a postactivate hook I can define. Now when I do

$ workon pitz

to start my work day, I get a customized work environment exactly the way I want it. In addition to activating a virtualenv named pitz, the postactivate script changes me into the top of my pitz checkout directory and then it starts up or reattaches a screen session customized just for pitz.

Setting this up was trivially easy. Here’s what my postactivate script looks like:
$ cat ~/.virtualenvs/pitz/bin/postactivate
cd /home/matt/projects/pitz
screen -S pitz -c ~/.screenrc-pitz -d -R

And here is that .screenrc-pitz file:
$ cat ~/.screenrc-pitz
# Matt's homemade .screenrc.

# Draw that blue and red bar across the bottom of the terminal, with the cute
# stuff like the window names and system CPU load.
hardstatus on
hardstatus alwayslastline
hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %l %{..Y} %m/%d %C%a "

# Let me scroll back a thousand lines or so.
defscrollback 1024

# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"

# tell screen how to set colors. AB = background, AF=foreground
termcapinfo mlterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'

# erase background with current bg color
defbce "on"

# Automatically start up a bunch of windows.
screen -t "shell" 0 pitz-shell
screen -t "code" 1
screen -t "tests" 2
chdir docs
screen -t "docs" 3

Everything from the top down to the comment # Automatically start up a bunch of windows. just tweaks how screen works. The last part creates a bunch of named windows. In the first wiindow, it doesn’t start a bash prompt. Instead it starts up the pitz-shell.

One tiny detail that may not be obvious is that if I do $ workon pitz in one terminal, and then maybe I ssh in and rerun $ workon pitz again later, I won’t cause a second screen to start up. Instead, I’ll remote-detach the original session and reconnect to it.

In practice, all my remote servers have highly customized screen sessions already waiting for me. I just need to log in and resume them, and I have all the interesting log files, database connections, and monitoring scripts already up. For example, I know my apache log is open in a pager in window 5. Window 2 has a psql session running. Window 1 has a supervisorctl client running.

This setup shaves off precious seconds when I’m trying to figure stuff out during an emergency.

This stuff isn’t rocket science, but I hope it helps somebody out.

23 thoughts on “virtualenvwrapper postactivate and screen is a wonderful combination

  1. Hello. I've been using virtualenvwrapper with screen for some time, but never took the time to think about stuff like postactivate, so thanks for the tip!

  2. just exactly what I needed, it looks simple.. why haven't I figured this out before, thanks a lot for the info, this is a great find indeed.

  3. I've tried creating environments with both version 0.9.2 and from SVN with the clean python install from Leopard and none of my environments are references the location of the globally installed packages. I just get absolutely clean environments every time without the PyObjC stuff!

  4. Pingback: A virtualenvwrapper hookokról —

  5. This doesn’t work for me. I source virtualenvwrapper in my bashrc. The package is only installed in my main Python installation, and not within the virtualenvs. If I activate a virtualenv, and then launch screen, I get the error “No module named virtualenvwrapper” since it’s not installed in that environment. Should I source it in bash_profile instead or something? Do you have virtualenvwrapper installed in every virtualenv?

  6. Hey Berk, Thanks for the comment. Do you have these lines in your ~/.bashrc:

    export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python
    source /usr/local/bin/

    I don’t think I have to install virtualenvwrapper within my virtualenv.

  7. Ah, I see, I didn’t know of the VIRTUALENVWRAPPER_PYTHON variable. Without that, when run with screen, the Python that’s in the virtualenv is used, which doesn’t have the package installed. Thanks!

Comments are closed.