FAQ
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?

Search Discussions

  • Ned Batchelder at Nov 25, 2013 at 12:46 pm

    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.
  • Jurko Gospodnetić at Nov 25, 2013 at 1:51 pm
    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?
  • Chris Angelico at Nov 25, 2013 at 1:04 pm

    On Mon, Nov 25, 2013 at 11:32 PM, Jurko Gospodneti? wrote:
    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.

    What this says to me is that you're doing something very unusual here
    - most people won't be doing that. So maybe you need an unusual
    solution.


    Is it possible to set up virtualization to help you out? Create a
    virtual machine in something like VirtualBox, then clone it for every
    Python patch you want to support (you could have one VM that handles
    all the .0 releases and another that handles all the .1 releases, or
    you could have a separate VM for every Python you want to test). You
    could then have a centralized master that each VM registers itself
    with, and it feeds out jobs to them. Assuming your tests can be fully
    automated, this could work out fairly efficiently - each VM has a
    script that establishes a socket connection to the master, the master
    hands out a job, the VMs run the test suite, the master collects up a
    series of Pass/Fail reports. You could run everything on a single
    physical computer, even.


    ChrisA
  • Jurko Gospodnetić at Nov 25, 2013 at 1:42 pm
    Hi.

    On 25.11.2013. 14:04, Chris Angelico wrote:
    Is it possible to set up virtualization to help you out? Create a
    virtual machine in something like VirtualBox, then clone it for every
    Python patch you want to support (you could have one VM that handles
    all the .0 releases and another that handles all the .1 releases, or
    you could have a separate VM for every Python you want to test).
    ...

        Thank you for the suggestion.


        Yup, we could do that, but at first glance it really smells like an
    overkill. Not to mention the potential licensing issues with Windows and
    an unlimited number of Windows installations. :-)


        So far all tests seem to indicate that things work out fine if we
    install to some dummy target folder, copy the target folder to some
    version specific location & uninstall. That leaves us with a working
    Python folder sans the start menu and registry items, both of which we
    do not need for this. Everything I've played around with so far seems to
    use the correct Python data depending on the interpreter executable
    invoked, whether or not there is a regular Windows installation
    somewhere on the same machine.


        We can use the script suggested by Ned Batchelder to temporarily
    change the 'current installation' if needed for some external installer
    package to correctly recognize where to install its content.


        I'm still playing around with this, and will let you know how it goes.


        Thank you again for replying!


        Best regards,
          Jurko Gospodneti?
  • Chris Angelico at Nov 25, 2013 at 1:47 pm

    On Tue, Nov 26, 2013 at 12:42 AM, Jurko Gospodneti? wrote:
    Yup, we could do that, but at first glance it really smells like an
    overkill. Not to mention the potential licensing issues with Windows and an
    unlimited number of Windows installations. :-)

    Ah, heh... didn't think of that. When I spin up arbitrary numbers of
    VMs, they're always Linux, so licensing doesn't come into it :)

    So far all tests seem to indicate that things work out fine if we install
    to some dummy target folder, copy the target folder to some version specific
    location & uninstall. That leaves us with a working Python folder sans the
    start menu and registry items, both of which we do not need for this.
    Everything I've played around with so far seems to use the correct Python
    data depending on the interpreter executable invoked, whether or not there
    is a regular Windows installation somewhere on the same machine.

    Okay! That sounds good. Underkill is better than overkill if you can
    get away with it!


    Good luck. You'll need it, if you're trying to support Python 2.4 and
    all newer versions AND manage issues across patch releases...


    ChrisA
  • Terry Reedy at Nov 25, 2013 at 4:38 pm

    On 11/25/2013 8:42 AM, Jurko Gospodneti? wrote:


    So far all tests seem to indicate that things work out fine if we
    install to some dummy target folder, copy the target folder to some
    version specific location & uninstall.

    If the dummy folder had 3.3.0, you should not need to uninstall to
    install 3.3.1 on top of it. But it is easy and probably safest.

    That leaves us with a working
    Python folder sans the start menu and registry items, both of which we
    do not need for this. Everything I've played around with so far seems to
    use the correct Python data depending on the interpreter executable
    invoked, whether or not there is a regular Windows installation
    somewhere on the same machine.

    Just a reminder: you can run one file or set of files with multiple
    Pythons by putting 'project.pth' containing the same 'path-to-project'
    in the Lib/site-packages of each Python directory. I do this to test one
    file with 2.7 and 3.3 (and just added 3.4) without copying the file.


    --
    Terry Jan Reedy
  • Jurko Gospodnetić at Nov 25, 2013 at 4:58 pm
    Hi.

    On 25.11.2013. 17:38, Terry Reedy wrote:
    So far all tests seem to indicate that things work out fine if we
    install to some dummy target folder, copy the target folder to some
    version specific location & uninstall.
    If the dummy folder had 3.3.0, you should not need to uninstall to
    install 3.3.1 on top of it. But it is easy and probably safest.

        Without the uninstall step you get stuck with invalid registry and
    start menu items refering to an invalid path until you install another
    matching major.minor.X version.



    Just a reminder: you can run one file or set of files with multiple
    Pythons by putting 'project.pth' containing the same 'path-to-project'
    in the Lib/site-packages of each Python directory. I do this to test one
    file with 2.7 and 3.3 (and just added 3.4) without copying the file.

        Thanks for the tip. That might come in useful. At the moment I just
    run the pytest framework using different python interpreters, without
    having to install the package at all (possibly first running 'setup.py
    build' to get the sources converted to Python 3 format).


        Best regards,
          Jurko Gospodneti?
  • Jurko Gospodnetić at Nov 27, 2013 at 5:33 pm
    Hi.

    On 25.11.2013. 14:42, Jurko Gospodneti? wrote:
    So far all tests seem to indicate that things work out fine if we
    install to some dummy target folder, copy the target folder to some
    version specific location & uninstall. That leaves us with a working
    Python folder sans the start menu and registry items, both of which we
    do not need for this. Everything I've played around with so far seems to
    use the correct Python data depending on the interpreter executable
    invoked, whether or not there is a regular Windows installation
    somewhere on the same machine.

    We can use the script suggested by Ned Batchelder to temporarily
    change the 'current installation' if needed for some external installer
    package to correctly recognize where to install its content.

    I'm still playing around with this, and will let you know how it goes.

        Just wanted to let you know that the usage I described above seems to
    work in all the cases I tried out.


        I added some batch scripts for running a specific Python interpreter
    as a convenience and everything works 'naturally' in our development
    environment.


        Packages can be easily installed to a specific targeted environment
    using for example:
        py243 -m easy_install pip
        py332 -m pip install pytest
    [not mentioning tweaks needed for specific ancient Python versions]


        Thank you all for all the suggestions.


        Best regards,
          Jurko Gospodneti?
  • Albert-Jan Roskam at Nov 25, 2013 at 1:20 pm
    --------------------------------------------
    On Mon, 11/25/13, Jurko Gospodneti? wrote:


      Subject: Parallel Python x.y.A and x.y.B installations on a single Windows machine
      To: python-list at python.org
      Date: Monday, November 25, 2013, 1:32 PM


      ? 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?


    HI Jurko,


    Check out the following packages: virtualenv, virtualenvwrapper, tox
    virtualenv + wrapper make it very easy to switch from one python version to another. Stricly speaking you don't need virtualenvwrapper, but it makes working with virtualenv a whole lot easier.Tox also uses virtualenv. You can configure it to sdist your package under different python versions. Also, you can make it run nosetests for each python version and/or implementation (pypy and jython are supported)


    Albert-Jan
  • Jurko Gospodnetić at Nov 25, 2013 at 1:57 pm
    Hi.

    On 25.11.2013. 14:20, Albert-Jan Roskam wrote:
    Check out the following packages: virtualenv, virtualenvwrapper, tox
    virtualenv + wrapper make it very easy to switch from one python
    version to another. Stricly speaking you don't need
    virtualenvwrapper, but it makes working with virtualenv a whole lot
    easier.Tox also uses virtualenv. You can configure it to sdist your
    package under different python versions. Also, you can make it run
    nosetests for each python version and/or implementation (pypy and
    jython are supported)

        I'll look into using virtualenv and possibly tox once I get into
    issues with mismatched installed Python package versions, but for now
    I'm dealing with installing different Python interpreter versions and,
    unless I'm overlooking something here, virtualenv does not help with
    that. :-(


        Thanks for the suggestion though, I'm definitely going to read up on
    those packages soon. :-)


        Best regards,
          Jurko Gospodneti?
  • Albert-Jan Roskam at Nov 25, 2013 at 2:15 pm
    --------------------------------------------
    On Mon, 11/25/13, Jurko Gospodneti? wrote:


      Subject: Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
      To: python-list at python.org
      Date: Monday, November 25, 2013, 2:57 PM


      ? Hi.

      On 25.11.2013. 14:20, Albert-Jan Roskam wrote:
    Check out the following packages: virtualenv,
      virtualenvwrapper, tox
    virtualenv + wrapper make it very easy to switch from
      one python
    version to another. Stricly speaking you don't need
    virtualenvwrapper, but it makes working with virtualenv
      a whole lot
    easier.Tox also uses virtualenv. You can configure it
      to sdist your
    package under different python versions. Also, you can
      make it run
    nosetests for each python version and/or implementation
      (pypy and
    jython are supported)

      ? I'll look into using virtualenv and possibly tox once
      I get into issues with mismatched installed Python package
      versions, but for now I'm dealing with installing different
      Python interpreter versions and, unless I'm overlooking
      something here, virtualenv does not help with that. :-(


      ====> Are you sure? http://stackoverflow.com/questions/1534210/use-different-python-version-with-virtualenv


    Below is a little terminal session. I often switch between python 3.3 and python 2.7. My virtualenv for python 3.3 is called "python33". "workon" is a virtualenv wrapper command. And check out the envlist in tox.ini on http://tox.readthedocs.org/en/latest/example/basic.html


    antonia at antonia-HP-2133 ~ $ workon python3.3
    ERROR: Environment 'python3.3' does not exist. Create it with 'mkvirtualenv python3.3'.
    antonia at antonia-HP-2133 ~ $ workon python33
    (python33)antonia at antonia-HP-2133 ~ $ python
    Python 3.3.2 (default, Sep 1 2013, 22:59:57)
    [GCC 4.7.2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    quit()
    (python33)antonia at antonia-HP-2133 ~ $ deactivate
    antonia at antonia-HP-2133 ~ $ python
    Python 2.7.3 (default, Sep 26 2013, 16:38:10)
    [GCC 4.7.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    quit()
  • Chris Angelico at Nov 25, 2013 at 2:39 pm

    On Tue, Nov 26, 2013 at 1:15 AM, Albert-Jan Roskam wrote:
    Below is a little terminal session. I often switch between python 3.3 and python 2.7. My virtualenv for python 3.3 is called "python33". "workon" is a virtualenv wrapper command. And check out the envlist in tox.ini on http://tox.readthedocs.org/en/latest/example/basic.html

    That's two different minor versions, though. Can you have 3.3.1 and
    3.3.2 installed, by that method?


    Incidentally, if this were on Linux, I would just build the different
    versions in different directories, and then run them without
    installing. But the OP seems to have a solution that works, and I
    think it'll be the simplest.


    ChrisA
  • Jurko Gospodnetić at Nov 25, 2013 at 3:40 pm
    Hi.

    On 25.11.2013. 15:15, Albert-Jan Roskam wrote:
    ====> Are you sure? http://stackoverflow.com/questions/1534210/use-different-python-version-with-virtualenv

        Yup, I'm pretty sure by now (based on reading the docs, not trying it
    out though).


        Virtualenv allows you to set up different environments, each of them
    having a separate Python folder structure and each possibly connected to
    a separate Python interpreter executable. However, it does not solve the
    problem of getting those separate Python interpreter executables
    installed in the first place, which is the problem I was attacking. :-)


        Still playing around with my multiple installations setup here. Will
    let you know how it goes...


        So far, one important thing I noticed is that you need to run all
    your installations 'for the current user only', or otherwise it moves at
    least one DLL file (python24.dll) into a Windows system folder and then
    the next installation deletes it from there, and overwrites it with its
    own. :-( But I can live with that... :-)


        Best regards,
          Jurko Gospodneti?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedNov 25, '13 at 12:32p
activeNov 27, '13 at 5:33p
posts14
users5
websitepython.org

People

Translate

site design / logo © 2022 Grokbase