Django development tips

Working on a couple Django projects in tandem has me tuning my approach to using the built-in development server. I thought I’d share some of the techniques I’m using.

Here are the commands I’m going to talk about. If you understand it all from these lines, you’re done!

screen -S projectname
./manage.py runserver |& tee -a logs/devserver.log
^A ^D
tail -f logs/devserver.log
screen -r projectname
screen -list

Using screen

screen -S projectname

The GNU screen command is incredibly useful for all kinds of things, including longish-running processes that need to be checked and tweaked and stopped and started – like your Django development server. (Read more about screen if this is new to you.)

The -S option allows you to name your session, so that you can recall it by name later. This is handy if you’re running multiple screens (and you probably will be).

Starting the server

./manage.py runserver |& tee -a logs/devserver.log

The first part of this command, up to the pipe, is as usual (you’ll want to add a port number if you’re testing more than one project on the same IP). The rest:

• |& combines stdout and stderr together (the Django development server sends its messages to stderr, so a regular pipe doesn’t suffice).

• The tee -a command, for each line of input, displays it and appends it to the named file.

• logs/devserver.log is just my suggested location and name for the logfile. (The path is relative to the project directory, where manage.py lives. You can of course use whatever location you like.)

Keeping an eye on things

tail -f logs/devserver.log

After you detach from your screen session (ctrl-a, ctrl-d), it keeps chugging along in the background. If you want to watch the log for a minute, just issue this tail command, which displays new log entries as they come in. Cancel with ctrl-c.

This is better than sitting there watching the same stuff inside your screen session, because if you lose your connection to your server (which I do on a regular basis) you may find your screen session is hard to reconnect to, or, in some cases, that your runserver process has stopped. Plus, the log will keep track of everything; by default, screen has a fairly small buffer.

Reconnecting

screen -r projectname

If you need to manually futz with the server process (e.g. if you need to restart it because you’ve done something traumatic that its normal auto-reload can’t handle), reconnect with screen -r projectname, where “projectname” is whatever you named the session (obviously, I tend to name my session after the project).

If you can’t remember what names you’ve used for sessions, screen -list will list them.

That’s all

If you have alternate suggestions, or corrections, feel free to post them to the comments.

Andrew commented on Tue Feb 14 16:11:36 2006:

I never even thought of that. I did notice that I was starting and stopping the server a lot. I guess I’ll have to fix my screen install on Mac OSX, somethings buggy.

tabo commented on Wed Feb 15 12:01:02 2006:

I use screen too but I have this scheme for developing django apps:

screen 0: django’s runserver screen 1: some template screen 2: models screen 3: views screen 4: urls screen 5: django’s shell screen 6: psql screen 7: svn screen 8+: random stuff

I use the exact same scheme for all my django projects. First thing I do in the morning is reattach the django screen session from my dev server (I never close it).

I don’t store django’s runserver logs, when I test stuff I just CTRL+a 0 and read the logs in real time. Any reason to keep this dev logs in disk? (other than historical reasons of course).

Doug commented on Wed Feb 15 12:19:34 2006:

An alternative to “tail -f” that I prefer is to open the log file in less and then hit “F” (shift-F) which will take you to the bottom of the log file and continually load the new stuff just like “tail -f”.

The benefit from using “less” instead of “tail -f” is that you can hit ctrl-C and you’re back in normal less operation – you scroll back in the buffer easily, search for text, etc. Hit “F” again and you’re looking at the latest stuff.

I still run it inside screen. screen rocks.

Paul commented on Wed Feb 15 13:27:34 2006:

Tabo: Very cool, you’re clearly a screen ninja. The main reason I currently use a logfile instead of keeping the screen session open all the time is that I often am on flaky wireless connections, and in the past have had trouble reattaching to stranded screen sessions.

Doug: Thanks for the less tip, that’s excellent.

rezzrovv commented on Wed Feb 15 14:39:44 2006:

I just keep a terminal tab devoted to the runserver (versus screen) as I like to insert “import pdb; pdb.set_trace()” quite often in my own code and sometimes in core django code as well.

I also use a lot of print statements which are printed to the console. Not sure why not just stay attached to the console?

Aaron commented on Wed Feb 15 17:13:27 2006:

I also use a similar layout, but I recommend running it behind apache using mod_proxy.

its only takes a second to setup and you can spin up django’s dev server from any directory and insert into your staging environment.

Paul commented on Thu Feb 16 10:49:24 2006:

Yeah, in fact I use Apache mod_rewrite proxy rules to the same effect. With domain wildcarding I can use a subdomain for each project under development, e.g. wiki.django.e-scribe.com.

Denis commented on Thu Feb 23 02:57:22 2006:

I wonder which shell do you use? I tried ``|&’’ in bash and it says “bash: syntax error near unexpected token `&’” Im using GNU bash, version 3.00.0(1)-release

Paul commented on Thu Feb 23 08:06:17 2006:

Sorry, I should have noted that I’m using tcsh.

germ commented on Mon Apr 10 19:35:44 2006:

I have a setup similar to tabo’s, which can be found here: http://germ.wordpress.com/2006/04/07/django-screen-environment/

germ commented on Mon Apr 10 19:37:30 2006:

oh yeah… Paul, “autodetach on”, might help with your reattach problem after your disconnects.