Virtualenv is a new product by Ian Bicking which aims to combine the best features of a workingenv with a virtual Python install. It allows you to set up an isolated Python environment whose libraries do not affect programs outside it, making it a good choice for experimenting with new packages or to deploy different programs with conflicting library requirements.
There is no official homepage but the following links should be useful:
http://pypi.python.org/pypi/virtualenv
http://blog.ianbicking.org/2007/10/10/workingenv-is-dead-long-live-virtualenv/
You don't actually need to install virtualenv in order to use it. To download it manually do the following:
wget http://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.0.tar.gz#md5=fb86aabdfc2033612b936cf08ad811ec
tar zxfv virtualenv-1.0.tar.gz
mv virtualenv-1.0/virtualenv.py ./
You can remove the other files if you like:
rm -r virtualenv-1.0
rm virtualenv-1.0.tar.gz
If you do want to install it you can use Easy Install:
Either way at some point you should have a script called ``virtualenv.py`` either in your current working directory or your Python scripts directory.
On Debian Etch you need these packages if you want to use it with Python 2.5:
sudo apt-get install python2.5 python2.5-dev
On Windows you will need a tool such as 7-zip from http://www.7-zip.org to extract the .tar.gz file.
You are now ready to create a virtual Python environment. Here's how it looks on Windows:
C:\>C:\Python25\python.exe "C:\Documents and Settings\Administrator\Desktop\virt
ualenv-1.0\virtualenv.py" sandbox
New python executable in sandbox\Scripts\python.exe
Installing setuptools...............................done.
Notice that it installs setuptools for you too. You can now install Pylons into your virtualenv:
C:\>sandbox\Scripts\easy_install.exe "Pylons==0.9.6.1"
If you run your normal Python executable you'll see Pylons isn't installed:
C:\>C:\Python25\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylons
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named pylons
>>>
but if you use your virtualenv one it is:
C:\>sandbox\Scripts\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylons
>>>
This means that your virtualenv sandbox is isolated from your system Python. BUT: if you install extra software in your system Python it will automatically become available to your virtualenv sandbox.
Now lets create and run a Pylons app:
C:\>sandbox\Scripts\paster create -t pylons Test
C:\>cd Test
C:\Test>..\sandbox\Scripts\python setup.py develop
C:\Test>..\sandbox\Scripts\paster serve development.ini
Your Pylons app will be at http://127.0.0.1:5000/ although depending on your firewall settings you may be prompted to unblock python.
 |
On windows you shouldn't create the virtualenv sandbox in a path with a space. Otherwise you get this error:
ValueError: The executable 'C:
Documents and Settings\\Administrator\\Desktop
sandbox\\Scripts
python.exe' contains a space, and in order to handle this issu
e you must have the win32api module installed |
|
Virtualenv is currently incompatible with distutils.cfg and ~/.pydistutils.cfg. If you have either of these files, virtualenv will put easy_install into the bin directory specified in the config file, rather than into the virtualenv where it belongs. |
On linux systems the executable files are kept in a bin directory within your sandbox, not a Scripts directory.
Activating the sandbox
Another way to use your sandbox is to "activate" it. This puts the sandbox executables first in your path, so you can run them without typing the full path to the sandbox. Here's how it looks on Windows:
C:\Test>..\sandbox\Scripts\activate.bat
(sandbox) C:\Test>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylons
>>>
Once you've activated a sanbox with activate.bat the scripts in the sandbox take precedence over the normal system ones. In the example above you can see that running python actually runs the version in your sandbox where Pylons is installed, and not the main system Python. The same is true for the other scripts available. Notice how the command prompt changes to show you that you are in a sandbox.
You can deactivate it with deactivate.bat and things go back to normal:
(sandbox) C:\Test>..\sandbox\Scripts\deactivate.bat
C:\Test>
And here on Ubuntu Linux:
$ mkdir ~/venv
$ virtualenv.py ~/venv/sandbox
$ source ~/venv/sandbox/bin/activate
(sandbox)$ easy_install Pylons==0.9.6.1
...
Installed /home/mso/venv/sandbox/lib/python2.5/site-packages/Pylons-0.9.6.1-py2.5.egg
...
$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylons
>>> pylons
>>> [ctrl-d]
(sandbox)$ deactivate
$
This user keeps several virtual environments in a ~/venv directory, each with a different configuration. But more importantly, he "sourced" the activate script rather than running it. You must 'source' the activate script on Unix systems, including Macintosh! The reason is that it modifies the current shell's environment, which is impossible if you run the script the normal way. In the original Bourne shell and possibly some others, the syntax is ". SCRIPTNAME" instead of "source SCRIPTNAME".
Not also how the prompt changed to "(sandbox)$" to remind you which environment you're in. The user was able to run the sandbox versions of "easy_install" and "python" without typing the full path; the same would be true of "paster".
At the end, the user ran "deactivate" to return to his normal shell environment. "deactivate" on Unix systems is a shell alias, so you don't have to "source" it.
There is one potential problem to keep in mind with activate/deactivate. The shell keeps the path of each command in memory so it doesn't have to look it up again when the command is re-executed. This bypasses activate's changes to the environment, so activate/deactivate try to clear this cache but sometimes they fail. The result is you type the command name and get the "wrong" one. To make 100% sure you're getting the right command, run "which python" (or "which easy_install", etc) and it will print the full path of the command it would have executed. If it's the wrong one, execute it once by typing the full path, and it will update the memory cache to use that version of the command.
Virtualenv.py options
Virtualenv.py has two interesting command-line options:
- --no-site-packages: don't make the global site-packages directory accessible in the virtual environment.
- --clear: delete any previous install of this virtualenv and start from scratch.
You can customize easy_install's behavior via the file "lib/python2.5/distutils/distutils.cfg" in the virtualenv.
For instance, to force easy_install to install all eggs as directories rather than zipfiles, add this:
[easy_install]
zip_ok = 0
