|Ned Batchelder : Blog | Code | Text | Site|
Installing Python packages from Windows installers into virtualenv
» Home : Blog : July 2010
Note (Feb 3, 2016): the latest and best version of this is Alex Waters' onetruepython. Use that.
I'm a recent convert to virtualenv, it's a great way to maintain a number of different Python installations so that you can install packages for one project without it polluting the environment for all your projects.
I also work on Windows, which can be a pain. In particular, many interesting Python packages involve compiling extensions, which is not always easy, and especially not easy on Windows. So I'm glad when package authors provide pre-built binaries for Windows. These are typically delivered as .exe Windows installers.
Here's the problem: these installers know to look in the registry to find the Python installation. There are many things developers dislike about Windows, and the registry is often at the top of the list. One of the bad things about it is that it encourages a mindset of their being one of everything. Starting with the concept of "one registry", it seeps into the whole culture of Windows, invading even to Python, which cannot abide more than one installation of a major release.
So when running a Windows package installer, it will find the Python 2.6 installation in the registry, and that's the only option you've got for where the code is going to go. Your nice isolated virtualenvs are completely out of the picture.
I asked on Stack Overflow if there's a way to install Windows package installers into virtualenvs, and didn't get the answers I wanted.
So I decided the best approach was to change the registry, install my package, then change the registry back. I adapted a classic script to register Python installations, to create what I've called the_python.py:
Use your desired Python to run this script, and it will be entered into the registry as the Python. When you run your Windows package installer, it will go into your virtualenv. Don't forget to run it again at the end to put things back the way they were.
Updated Nov 12, 2013: Alex Waters ([Tritium] on #python) revised the program to detect the need for elevated privileges and automatically re-run itself with privileges. This makes it much more convenient. Thanks, Alex!
Updated Feb 3, 2016: Alex Waters continues dominance in this area: his latest version is at onetruepython.