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.