| Name |
Space |
Page |
Section |
Version |
Status |
Reviewed |
Author(s) |
| Getting Started with workingenv |
Pylons CookBook |
Getting Started with workingenv |
Home |
1.0 |
Draft |
False |
 James Gardner |
Introduction
When you are working with lots of Pylons applications on the same server you quickly come across a situation where you want to be able to isolate the packages used by one Pylons application from the others.
There are two ways to do this. The first is on a per-user basis using a virtual Python install (described here), the other is to use workingenv.
Using a workingenv is about as close as you can get to managing all your scripts and libraries manually yourself whilst ensuring they don't interfere with each other. The way workingenv works is that you source a script which sets up all your PATH variables differently so that the normal system Python uses the versions of scripts and libraries in your workingenv directory instead of the usual places.
This means that any time you wish to use software in your workingenv you have to activate it (to setup the paths). Luckily this is very easy and flexible.
Installation
You can install workingenv from the cheeseshop or directly like this:
wget http://svn.colorstudy.com/home/ianb/workingenv/workingenv.py
You can then setup a workingenv environment like this:
python workingenv.py new-working-env
source new-working-env/bin/activate
If you are running Windows you can run this instead of the second command:
new-working-env/bin/activate.bat
This sets up a modified version of easy_install so that any software installed by easy_install goes to the correct place. It also makes changes to a local site.py file so that Python uses the correct installed modules. Activating your working environment changes your shell environment so that any commands you enter run from and affect the working environment not the main Python installation. Be aware that unlike a virtual Python install, there is nothing at the operating system level stopping the wrong commands being run, it is simply that the shell you activated will behave as if your working environment is the only one around.
Once the shell has been activated the prompt changes to remind you which environment you are in:
(new-working-env)workingenv@dev:~$
If you now run the python command and have a look at sys.path you will see everything has been setup for the new environment:
1
2
3
4
5
6 | Python 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.
>>> import sys
>>> print sys.path
['', '/home/workingenv/new-working-env/lib/python2.4', '/usr/lib/python24.zip', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/home/workingenv/new-working-env/lib/python2.4/setuptools-0.6c5-py2.4.egg']
|
At this point you can try to install some software:
You will see that Pylons and its dependencies have been installed to the working environment, not the system site=packages directory:
ls -l new-working-env/lib/python2.4
 |
Remember that you have to activate your environment by running the source new-working-env/bin/activate command every time you open a new shell and wish to work in the environment. |
 | Alternative presentation of sys.path using prettyprinting to get linebreaks... |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | Python 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.
>>> import sys
>>> from pprint import pprint
>>> pprint(sys.path)
['',
'/home/workingenv/new-working-env/lib/python2.4',
'/usr/lib/python24.zip',
'/usr/lib/python2.4',
'/usr/lib/python2.4/plat-linux2',
'/usr/lib/python2.4/lib-tk',
'/usr/lib/python2.4/lib-dynload',
'/home/workingenv/new-working-env/lib/python2.4/setuptools-0.6c5-py2.4.egg'
]
|
Installing Software into your workingenv
You can install software as usual but you will need to manually specify the lib and bin directories. You must be in your activated environment first:
1 | easy_install-2.4 -d /home/workingenv/new-working-env/lib/python2.4 -s /home/workingenv/new-working-env/bin "Pylons==0.9.5"
|
Serving a Pylons app From the workingenv
To server a Pylons app first activate the working env:
1 | source new-working-env/bin/activate
|
then run the paster serve command as usual:
1 | paster serve --reload development.ini
|
In cron Jobs
If you want to run a Pylons app from a working env using a cron job you can do so like by including the workingenv activation as part of the script. Here's an exceprt from one of mine:
16,32,33,34,36,56 * * * * cd /home2/indications/workingenv; source packyears/bin/activate; cd ../webapps/packyears; paster serve --daemon development.ini
Deactivting a workingenv
Once you have finished using your working env run this command to deactivate it:
