Parallel Python x.y.A and x.y.B installations on a single Windowsmachine

[Jurko Gospodnetiæ]

Hi all.

I was wondering what is the best way to install multiple Python
installations on a single Windows machine.

Regular Windows installer works great as long as all your
installations have a separate major.minor version identifier. However,
if you want to have let's say 2.4.3 & 2.4.4 installed at the same time
it does not seem to work.

I have not been able to find any prepackaged Python installation or
really any solution to this. Most of the advice seems to boil down to
'do not use such versions together, use only the latest'.

We would like to run automated tests on one of our projects (packaged
as a Python library) with different Python versions, and since our code
contains workarounds for several problems with specific Python patch
versions, we'd really like to be able to run the tests with those
specific versions and with as little fuss as possible.

Looking at what the Python installer does, the only problematic part
for working around this manually seems to be the registry entries under
'Software\Python\PythonCore\M.m' where 'M.n' is the major.minor version
identifier. If Python interpreter expects to always find its entries
there, then I guess there is no way to do what we need without building
customized Python executables. Is there a way to force a specific Python
interpreter to not read in this information, read it from an .ini file
or something similar?

Many thanks.

Best regards,
Jurko Gospodnetiæ

 

[Ned Batchelder]

Hi all.

I was wondering what is the best way to install multiple Python
installations on a single Windows machine.

Regular Windows installer works great as long as all your
installations have a separate major.minor version identifier. However,
if you want to have let's say 2.4.3 & 2.4.4 installed at the same time
it does not seem to work.

I have not been able to find any prepackaged Python installation or
really any solution to this. Most of the advice seems to boil down to
'do not use such versions together, use only the latest'.

We would like to run automated tests on one of our projects (packaged
as a Python library) with different Python versions, and since our code
contains workarounds for several problems with specific Python patch
versions, we'd really like to be able to run the tests with those
specific versions and with as little fuss as possible.

Looking at what the Python installer does, the only problematic part
for working around this manually seems to be the registry entries under
'Software\Python\PythonCore\M.m' where 'M.n' is the major.minor version
identifier. If Python interpreter expects to always find its entries
there, then I guess there is no way to do what we need without building
customized Python executables. Is there a way to force a specific Python
interpreter to not read in this information, read it from an .ini file
or something similar?

Many thanks.

Best regards,
Jurko GospodnetiÄżË

IIRC, Python itself doesn't read those registry entries, except when installing pre-compiled .msi or .exe kits. Once you have Python installed, you can move the directory someplace else, then install another version of Python.

If you need to use many different Pythons of the same version, this script helps manage the registry: http://nedbatchelder.com/blog/201007/installing_python_packages_from_windows_installers_into.html

--Ned.

 

[Jurko Gospodnetić]

Hi.

IIRC, Python itself doesn't read those registry entries, except when installing pre-compiled .msi or .exe kits. Once you have Python installed, you can move the directory someplace else, then install another version of Python.

If you need to use many different Pythons of the same version, this script helps manage the registry: http://nedbatchelder.com/blog/201007/installing_python_packages_from_windows_installers_into.html

Thank you for the information!

As I mentioned in another reply, so far I think we can use this
script to temporarily change the 'current installation' if needed for
some external installer package to correctly recognize where to install
its content.

<bike-shedding>If we do use it, I'll most likely modify it to first
make a backup copy of the original registry key and use that later on to
restore the original registry state instead of reconstructing its
content to what the script assumes it should be.</bike-shedding>

Best regards,
Jurko Gospodnetić