environmentName\Scripts\deactivate.bat How does virtualenv work When one creates an environment, inside it three folders are created: • bin: when one has the environment active, and executes a command like python, pip or easy_install, one of the binaries in this folder is ran, instead of the system’s. • include: it’s simply a link to the files installed with <strong>Python</strong>. • lib: this is another important folder. Just like include it has a folder named python, but in contrast to include, this one isn’t a link to the files installed with <strong>Python</strong>. Instead, the folder has two important things: • A link to some <strong>Python</strong> files. In this case, the .py • A folder, site-packages, which is where packages are installed when one uses pip or easy_install Q & A session (Part 1) Before I commented that one of the problems we had was that we couldn’t install two <strong>version</strong>s of the same library. What I never did is comment how this problem is solved. The solution is easy. You create a virtual environment to use with django 0.97, and another for 1.2. You can create as many virtual environments as you wish, and they’re isolated from each other. For production servers, there are configurations that can be set up in apache for it to use some specific virtual environment. Q & A session (Part 2) I create a virtualenv, activate it, and do pip freeze, and lots of things that I never installed appear in the environment. The default behavior of virtualenv when one creates an environment is to also create it with the packages one has installed in the system. For it not to do this, when you create the environment, you can do: virtualenv --no-site-packages environmentName This makes it create a completely empty environment. Lastly, another option to note is —python, which makes the virtual environment use that <strong>version</strong> of python (it is necessary to have installed that <strong>version</strong> for this to work). For instance, in my machine I have both <strong>Python</strong> 2.7 and 3.1, being 2.7 the default one. Thus, when I create an environment, it will be created with <strong>Python</strong> 2.7. For it to use <strong>Python</strong> 3.1, I have to do the following: virtualenv --python=python3.1 environmentName Q & A session (Part 3) There are some packages that have code written in C. What happens with those Well, in those cases pip or easy_install will try to build the C code when the package is installed. In distros like Ubuntu, I recommend installing: • build-essential • python-dev Those two packages make it much easier to build. However, in Windows it is not so easy. Several packages that have C code are distributed as an .exe too. However, those installers do not allow us to select where to install them. Here http://www.developerzen.com/2010/09/23/the-complete-guide-to-setting-up-python-develo is a very good guide on how to make it build packages as it downloads it. Q & A session (Part 4) Do you recommend installing system packages or is it better to use easy_install There are various distros that come with various python packages that can be installed in the system. For example: apt-get python-numpy python-reportlab python-pil But the <strong>version</strong>s that can be installed with apt-get are old. Here we’ll see some comparative examples: Package name Ubuntu 10.10 <strong>version</strong> PyPi <strong>version</strong> rst2pdf 0.14.2 0.16 reportlab 2.4.3 2.5 django 1.2.3 1.2.3 Thus, it depends on what one wants to do. For instance, if one wants to make a program work with Ubuntu, then one can create a virtual environment and install the same
<strong>version</strong>s that apt-get has, or directly install system-supplied ones. What I would NOT recommend is overwriting the installed <strong>version</strong>. For instance, if one does: apt-get python-reportlab Then you do NOT do: easy_install -U reportlab Not without using a virtual environment, because it could break the system.