January 02, 2011
In the virtualenv documentation, Ian Bicking gives a recipe for creating project bootstrap scripts that set up an environment and then perform custom steps to populate it. The bootstrap script is self-contained: it doesn't require the person running it to have virtualenv installed. The downside is that producing the bootstrap script requires running another script that invokes
virtualenv.create_bootstrap_script and writing the result to disk.
If you're willing to treat virtualenv as a pre-requisite, there's an alternative recipe that doesn't require the script-creating-a-script level of indirection. Import the
virtualenv module, define the hook functions in its scope, and then execute its
For example, here's a bootstrap script that creates a virtual environment, installs the HEAD of the Tornado's master branch from GitHub, writes a script that runs a Tornado server with a static file handler pointing to a
www directory, makes the run script executable, and dumps a hello world
index.html file into the root of the static path.
You can execute this script, giving it a path to where you want the virtual environment to reside. After it completes, you can activate that environment and execute the
run_server.py script it generates to start the Tornado server. Visiting
http://localhost:8080/static/index.html in your browser shows the hello world page the
$ ./setup_tornadoenv.py ~/envs/my_app $ source ~/envs/my_app/bin/activate $ run_server.py & $ open http://localhost:8080/static/index.html
Of course, you can reuse the setup script to create additional, isolated environments.
$ deactivate # get out of the my_app env $ ./setup_tornadoenv.py ~/envs/my_other_app $ . ~/envs/my_other_app/bin/activate $ run_server.py --port=9000 & $ open http://localhost:9000/static/index.html
If you install virtualenvwrapper, switching among the separate server environments is even easier.
$ deactivate # get out of the my_other_app env $ sudo pip install virtualenvwrapper $ export WORKON_HOME=~/envs # or add this to .bashrc or .bash_profile $ source /usr/local/bin/virtualenvwrapper.sh # same here $ workon my_app # now in the my_app env $ workon my_other_app # now in the other $ deactivate # now in the system env
You can always add arguments to the bootstrap script to increase its flexibility too. Imagine options for what version of Tornado to fetch, the default port number, manging the server under supervisord, etc.