Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #60411 > unrolled thread

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

Started byJurko Gospodnetić <jurko.gospodnetic@pke.hr>
First post2013-11-25 13:32 +0100
Last post2013-11-25 14:51 +0100
Articles 3 — 2 participants

Back to article view | Back to comp.lang.python


Contents

  Parallel Python x.y.A and x.y.B installations on a single Windows machine Jurko Gospodnetić <jurko.gospodnetic@pke.hr> - 2013-11-25 13:32 +0100
    Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine Ned Batchelder <ned@nedbatchelder.com> - 2013-11-25 04:46 -0800
      Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine Jurko Gospodnetić <jurko.gospodnetic@pke.hr> - 2013-11-25 14:51 +0100

#60411 — Parallel Python x.y.A and x.y.B installations on a single Windows machine

FromJurko Gospodnetić <jurko.gospodnetic@pke.hr>
Date2013-11-25 13:32 +0100
SubjectParallel Python x.y.A and x.y.B installations on a single Windows machine
Message-ID<mailman.3166.1385382760.18130.python-list@python.org>
   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ć

[toc] | [next] | [standalone]


#60412

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-11-25 04:46 -0800
Message-ID<107e2c79-ae7b-4798-b07c-e52af62c68a4@googlegroups.com>
In reply to#60411
On Monday, November 25, 2013 7:32:30 AM UTC-5, Jurko Gospodnetić wrote:
> 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.

[toc] | [prev] | [next] | [standalone]


#60419

FromJurko Gospodnetić <jurko.gospodnetic@pke.hr>
Date2013-11-25 14:51 +0100
Message-ID<mailman.3173.1385387495.18130.python-list@python.org>
In reply to#60412
   Hi.

On 25.11.2013. 13:46, Ned Batchelder wrote:
> 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ć

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web