Clone wiki

imp / Home

For IMP developers

Note that this document refers to the IMP deployment on flipendo. It is specific to this instance, and is not a general imp deployment guide.

General development

Development should be carried out in the imp-dev instance located at


This instance of IMP has it's own database (the development database). It is therefore acceptable to run migrations on imp-dev. When creating migrations, insure that any delete operations on the database (removing tables, columns, etc.) are the final database changes before moving to imp-stage, and that they are not encompassed in any required migrations (i.e. adding columns, tables, etc). IMP dev is served at In terms of settings, imp-dev should usually have DEBUG=True.

Moving changes to production

There are staging and production instances of IMP. These are served at and The code for each can be found in




The 'www' directories in each of these are symlinks to either imp-dog or imp-cat. Whichever of these is pointed to by imp/www will be served at

To update the code running on the public imp server without downtime, go to the staging instance. Pull changes, and run any database migrations THAT DO NOT DELETE TABLES OR COLUMNS. Test this webserver through When you are satisfied with the situation, change the symlink at /Genomics/local/imp/www to point to the newly updated imp code (imp-dog or imp-cat), and change the symlink at /Genomics/local/imp-stage/www to point to the other directory. Once the new code is live at, database migrations can be run that delete tables or columns.

Please note that in imp-dog and imp-cat should never be deployed publicly (to with DEBUG=True set. If you do need to work on imp-stage with debug, make sure you turn it off before switching it to the production (imp) instance.

Clearing the Cache

imp-dog and imp-cat each add separate keys to the cache. This means that switching imp-stage and imp should be enough to make new templates, etc, live. Everything is cached for 24 hours (unless the cache fills up) so as long as imp-dog and imp-cat aren't switched more frequently than that, there should not be an issue. In the case that someone does wish to clear the cache, run

source imppy/bin/activate
python shell

to get a django shell. Then inside the shell run

from django.core.cache import cache

Setting up virtualenv

mkdir imppy
virtualenv --no-site-packages imppy
source imppy/bin/activate

# Current hack for haystack beta
pip install -e git://

pip install -r requirements.txt