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.
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!
Thanks for sharing – I didn't know about this feature of virtualenvwrapper and was inspired to write a plugin for Rip (Ruby version of pip + virtualenv + virutalenvwrapper) to emulate this behavior: http://groups.google.com/group/rip-rb/browse_th…
Cheers!
nice descrption of your best practise! will try that sometime.
Hey Matt,
I just wanted to say thanks for the tip / screen config. Your post motivated me to setup screen over here at Penny Arcade to centralize our administration.
http://www.penny-arcade.com/uploads/2009/08/17/…
Thanks again!
This is a nice step by step article with lots of usuful code. Thank you very much for sharing it.
This is a nice coding. Very much useful for my work. Thanks for share this great work.
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.
Thanks for sharing us those tips I will surely be using those tips for screen config
this was really helpful, thanks for posting this tips..
thanks for sharing the information, great site, will revisit again.
This is very useful post.Nice description of your best practice! will try that sometime.
It is really great. i use virtualenvwrappe 2 years now 🙂
It is really great. i use virtualenvwrappe 2 years now 🙂
p.s keep up the good work matt
I tried it some months ago, and now i recommend it to you all.
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!
I like the idea. It seems cool.
Me too, thanks for your guys guide here.
Pingback: A virtualenvwrapper hookokról — Django.hu
Very nice, I'm gonna try some of these, i don't know if they will work with me as i with to, but i'm gonna give this a try.
…
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?
Hey Berk, Thanks for the comment. Do you have these lines in your ~/.bashrc:
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python
source /usr/local/bin/virtualenvwrapper.sh
I don’t think I have to install virtualenvwrapper within my virtualenv.
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!
Wonderful idea man Congrats!