Multiple Python installations on Windows

Thursday 29 December 2005This is over 17 years old. Be careful.

I’ve been developing on Windows for a long time. I’ve figured out the thing about Windows I dislike the most, and it is not one of the things that most people bitch about (monopoly, security holes, UI, whatever). The thing that gets me as a developer is the Windows mindset of there being only one of anything. This is exemplified by the registry. THE registry. Sure, you can build software so that it has multiple instances, and knows how to find them all in the registry, and pick the proper one, but generally, no one does that.

The latest problem along these lines is installing Python. There are two sources for Windows installers for Python: and ActiveState ActivePython. Both provide MSI files, which make it super-easy to install Python on your Windows machine. The problem is that MSI installations are based on the notion that a product is only installed once per machine. That’s a good model for most people, but as a developer, I’d like to manage a number of Python installations simultaneously. It lets me test software against multiple versions, and it lets me keep complex product installations separate.

If you’ve installed Python once from an MSI, the next install offers only the options to change, repair, or remove the installation. The MSI instructions mention a TARGETDIR option, but setting it doesn’t help: the “one installation per product” mindset pervades the installer.

ActivePython has .zip files available too, on their raw downloads page. These provide a .bat file for installation, and let you specify the install directory, which does create side-by-side installations. But the script doesn’t write the registry settings that let 3rd party packages find the Python installation.

I used to manage a number of installations. Have the installers changed? Am I losing my mojo? What’s the best way to keep a number of Pythons caged on Windows simultaneously?

Update: I found this page about how Python uses the registry (someone might want to look into what’s going on with that background image in Firefox!), and this script to register a Python installation in the registry. Perhaps this is the way to go? Manually re-register Python installations as needed to get modules to install in the proper places?


Do you mean multiple installs of Python of different *versions* and *distro*? I have ActivePython 2.0, 2.1, 2.2, 2.3 and 2.4 installed on my machine and (currently)'s Python 2.4.

There shouldn't be any conflicts for Python installs with a different MAJOR.MINOR because ActivePython changes the MSI "ProductCode" for each MAJOR.MINOR change and so does's installer (I believe). Is your experience different?

However, you are right that there are some subtle things thereafter, namely (1) the registry -- as you have indicated -- and (2) possible conflict for DLLs from separate distros but same MAJOR.MINOR in the system directory.

1. The Registry. I think the only real uses of the Python registry entries are (a) the indicate where Python is installed to 3rd party packages (typically ones that are built with distutils' bdist_wininst) and (b) the PythonPath key and subkey stuff (however, since '.pth' file support was added to Python a couple of versions back, I think this is out-dated). I don't believe the "Modules" subkey is used anymore, though I haven't looked too hard. The "Help" key is used, I think, by the Pythonwin editor that is part of PyWin32, but I think that could be changed.

2. Basically for the sake of COM Servers written in Python, one (or a few if using PyWin32) python-related DLL(s) are placed in the Windows system directory instead of in the Python install tree: pythonXY.dll, pythoncomXY.dll, pywintypesXY.dll. As a result installing, say, Python 2.4.x from and ActivePython 2.4.x you will get a conflict.'s Python installer allows for a user-only install to put pythonXY.dll in the install dir (I think that is what its user-only install does). ActivePython will place these DLLs in the Python install dir if the installing user is unpriviledged (i.e. cannot install to the system dir).

To try to answer your questions: Yes, the and ActivePython installers have changed over the years: moving to MSI, ActivePython re-writing some of the backend guts used to build its installers for various reason. You aren't losing your mojo. :)

> What's the best way to keep a number of Pythons caged on
> Windows simultaneously?

When we did the port of ActivePython over to Mac OS X I started writing a "" tool to help deal with the machinations of making a certain Python installation the "default" one. This was necessary to allow Mac users to try out ActivePython without destroying a MacPython installation of the same version. Perhaps we need to make this tool do the same kind of thing on Windows.

Then perhaps that can be integrated as part of the ActivePython "AS Package" installer for Windows (the simple .zip-based one you mentioned). Thereafter one could use "pydistro" to select the "current" MAJOR.MINOR Python for general usage -- similar to way one much call the appropriate vcvars32.bat et al for selecting a specific VC++ build environment.

Trent (ActivePython dude)
Java has the same issues with multiple versions. I'm not sure if the multi-version Java issues are really much easier to deal with on other platforms. Most Java application installers will look in the registry for pre-existing Java installations and, failing that, will do a brute-force scan for JRE installation directories. One reason for the latter approach is that not all Java installs are created equal. Sun's Java installer uses the registry, IBM's Java installers do not (or at least didn't up to 1.4).
Trent: thanks for the detailed information from the horse's mouth (so to speak). I had tried to install 2.4.2 and 2.4.1 from ActiveState, and they would not co-exist. You make clear why: they are both 2.4.

I guess I'm heading down the path of a script that lets me switch distributions (your pydistro sounds great). I have to come to grips with the rest of the registry settings. For example, the .py extension is registered to invoke a particular python.exe. Do I want to switch those over too? Maybe not necessary...
> I had tried to install 2.4.2 and 2.4.1...

Yah, it was a conscious decision to make all 2.4.x use the same ProductCode -- which in MSI result in disallowing having separate installs of the two. Eventually the ActivePython installer will just allow 2.4.2 to upgrade 2.4.1 in-place.

I think this makes sense for the common case, but I understand why you would want to have both installed. Using the "AS Package" (i.e. the .zip installer) is probably the best solution for you -- at least for all X.Y versions but one.

> For example, the .py extension is registered to invoke a
> particular python.exe. Do I want to switch those over too?

I would say, yes. You should be able to do that with a call to "ftype":
ftype Python.File="path\to\chosen\python.exe" "%1" %*`

See `ftype /?` and `assoc /?` for more info.

This may be serious overkill for your situation, but it's worth a thought: set up separate environments using VMWare or QEMU.
I have nothing to add to the python discussion (sorry), but the background image at is weird. It works fine in Firefox 1.5--Linux, but the same page in Opera has black lines going across the page, which makes it hard to read. I think there's an actual problem with the image, but it may be an html rendering issue.
I tried downloading the image and opening it in Gimp, and there were definite errors, so I think different rendering engines are handling it differently.
Keith, Ned,
I've send some feedback to the webmaster suggesting they drop the background image for that page.
I've had similar grief and have resorted to using VMWare like Dan Schwarz suggests.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.