Ned,
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) python.org'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 python.org'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 python.org and ActivePython 2.4.x you will get a conflict. Python.org'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 python.org and ActivePython installers have changed over the years: python.org 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 "pydistro.py" 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.

Ned,

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 python.org 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 python.org 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.