Pylons

Name	Space	Page	Section	Version	Status	Reviewed	Author(s)
Creating a Sandboxed Pylons Installation with a Virtual Python Install	Pylons CookBook	Creating a Sandboxed Pylons Installation with a Virtual Python Install	Home	1.0	Draft	False	James Gardner

Introduction

 If you are running a production server with multiple Pylons applications running it is useful to be able to keep them all completely separate so that you can use different versions of the same Python libraries for each running instance. We can achieve this on a Unix system by creating a different user for each Pylons application and using a virtual Python install for each one. Alternative approach, called 'workingenv' is described here: Getting Started with workingenv.

Getting Started

In this example we are going to setup a sandboxed blog application.

First we create the user called blog:

Then we install the software we need if we haven't already got it:

The python-dev and subversion packages are needed if you want to be able to use easy_install to install development versions of Python eggs. 

Next we make sure we are the blog user and in the blog user's home directory (~ is a shortcut in bash for the home directory if the current user):

We download the file we need to setup the virtual Python install:

wget http://peak.telecommunity.com/dist/virtual-python.py

Then we run the virtual python installation using the system-wide Python to setup our virtual Python installation:

python virtual-python.py

What this does it to copy the Python binary to the blog user's /home/blog/bin directory and setup symbolic links to the system wide libraries. This means that the ~/bin/python executable will have access to the same libraries as the system Python but that any extra installed software will not affect the system wide Python.

If you receive errors about missing include directories at this stage it is likely to be because you skipped the step which asked you to install the python-dev package at the start of this guide

Now that we have setup the virtual Python we can setup easy install. First download the ez_setup.py file:

wget http://peak.telecommunity.com/dist/ez_setup.py

Then install easy install. Remember to use the new ~/bin/python executable and not the system wide one:

$ ~/bin/python ez_setup.py

This command adds the easy_install command to the blog user's bin directory so we can now install Pylons:

$ ~/bin/easy_install Pylons

If there are problems check the Pylons install page. If you have problems compiling Cheetah, try manually installing it from a package appropriate for your platform. After installing it you will need to rerun the python virtual-python.py script to ensure that your virtual Python picks up the newly installed system wide Cheetah installation.

Using the New Setup

Now that you have your local setup you should ensure that you change any references to the system Python to point to your virtual Python. This means replacing the first line of any scripts to use #!/home/blog/bin/python rather than just python and using /home/blog/bin/easy_install and /home/blog/bin/paster instead of any system wide ones.

Give it a go now:

$ /home/blog/bin/pythonPython 2.4.4 (#2, Jan 13 2007, 17:50:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

If you have a Pylons app you can serve it like this:

/home/blog/bin/paster serve --reload development.ini

and if you want to install more packages you can do so like this:

/home/blog/bin/easy_install package_name

and it will be installed to your virtual Python install, not to the system wide Python installation.

Setting up Bash

You might find it easier to configure your shell so that by default scripts in your blog user's bin directory are executed before the system wide ones. This means that you can type the python, paster and easy_install commands and your user's virtual versions will be used instead of the system wide ones.

To set this up edit your .bash_profile file in the user's home directory and add this:

You will need to logout and login again for this to take effect or run this command:

source ~/.bash_profile

Be aware that doing this doesn't actually change the system commands, it just sets up your shell so that your virtual Python install's bin directory is checked first. You will still need to specify the correct paths to the commands in any scripts which are to be run by the system.

You can check which version of a command you are using with the which command:

which python
/home/blog/bin/python

Is This Suitable For Production Use?

Absolutely and in fact it is recommended because it is less likely you will accidentally install Python modules which affect your application. The author uses this approach for all production deployment of his Pylons sites.