Registry entries set up by the Windows installer

Discussion in 'Python' started by Paul Moore, Feb 1, 2012.

  1. Paul  Moore

    Paul Moore Guest

    I'm trying to get information on what registry entries are set up by
    the Python Windows installer, and what variations exist. I don't know
    enough about MSI to easily read the source, so I'm hoping someone who
    knows can help :)

    As far as I can see on my PC, the installer puts entries

    HKLM\Software\Python\PythonCore\x.y

    with various bits underneath. I think I've seen indications that
    sometimes these are in HKCU, presumably for a "per user" install? If I
    manually hack around in the registry, and have both HKLM and HKCU,
    which one will Python use?

    Furthermore, more of a Windows question than Python, but there's a
    similar question with regard to the .py and .pyw file associations -
    they can be in HKLM\Software\Classes or HKCU\Software\Classes. Which
    takes precedence? I assume that the installer writes to HKLM for all
    users and HKCU for per-user installs.

    Is there anything else I've missed?

    The reason I ask, is that I'm starting to work with virtualenv, and I
    want to see what would be involved in (re-)setting the registry
    entries to match the currently active virtualenv. virtualenvwrapper-
    powershell seems to only deal with HKCU (which is a big plus on
    Windows 7, as it avoids endless elevation requests :)) but that
    doesn't work completely cleanly with my all-users install. (Note: I'm
    not entirely sure that changing global settings like this to patch a
    per-console virtualenv is a good idea, but I'd like to know how hard
    it is before dismissing it...)

    Thanks,
    Paul.
    Paul Moore, Feb 1, 2012
    #1
    1. Advertising

  2. Paul  Moore

    Mark Hammond Guest

    On 2/02/2012 2:09 AM, Paul Moore wrote:
    > I'm trying to get information on what registry entries are set up by
    > the Python Windows installer, and what variations exist. I don't know
    > enough about MSI to easily read the source, so I'm hoping someone who
    > knows can help :)
    >
    > As far as I can see on my PC, the installer puts entries
    >
    > HKLM\Software\Python\PythonCore\x.y
    >
    > with various bits underneath. I think I've seen indications that
    > sometimes these are in HKCU, presumably for a "per user" install? If I
    > manually hack around in the registry, and have both HKLM and HKCU,
    > which one will Python use?


    For setting PYTHONPATH it uses both - HKEY_CURRENT_USER is added before
    HKEY_LOCAL_MACHINE. I can't recall which one distutils generated
    (bdist_wininst) installers will use - it may even offer the choice.

    > Furthermore, more of a Windows question than Python, but there's a
    > similar question with regard to the .py and .pyw file associations -
    > they can be in HKLM\Software\Classes or HKCU\Software\Classes. Which
    > takes precedence?


    No idea I'm afraid, but I'd expect it to use HKCU

    > I assume that the installer writes to HKLM for all
    > users and HKCU for per-user installs.


    Yep, I think that is correct.

    > Is there anything else I've missed?


    I'm also not sure which one the pylauncher project will prefer, which
    may become relevant should that get rolled into Python itself.

    > The reason I ask, is that I'm starting to work with virtualenv, and I
    > want to see what would be involved in (re-)setting the registry
    > entries to match the currently active virtualenv. virtualenvwrapper-
    > powershell seems to only deal with HKCU (which is a big plus on
    > Windows 7, as it avoids endless elevation requests :)) but that
    > doesn't work completely cleanly with my all-users install. (Note: I'm
    > not entirely sure that changing global settings like this to patch a
    > per-console virtualenv is a good idea, but I'd like to know how hard
    > it is before dismissing it...)


    Out of interest, what is the reason forcing you to look at that -
    bdist_wininst installers? FWIW, my encounters with virtualenv haven't
    forced me to hack the registry - I just install bdist_wininst packages
    into the "parent" Python which isn't ideal but works fine for me. This
    was a year or so ago, so the world might have changed since then.

    Mark
    Mark Hammond, Feb 2, 2012
    #2
    1. Advertising

  3. Paul  Moore

    Paul Moore Guest

    On 2 February 2012 00:28, Mark Hammond <> wrote:
    > For setting PYTHONPATH it uses both - HKEY_CURRENT_USER is added before
    > HKEY_LOCAL_MACHINE.  I can't recall which one distutils generated
    > (bdist_wininst) installers will use - it may even offer the choice.

    [...]
    > Yep, I think that is correct.


    Thanks for the information.

    >> Is there anything else I've missed?

    >
    > I'm also not sure which one the pylauncher project will prefer, which may
    > become relevant should that get rolled into Python itself.


    Good point - I can look in the source for that, if I need to.

    >> The reason I ask, is that I'm starting to work with virtualenv, and I
    >> want to see what would be involved in (re-)setting the registry
    >> entries to match the currently active virtualenv. virtualenvwrapper-
    >> powershell seems to only deal with HKCU (which is a big plus on
    >> Windows 7, as it avoids endless elevation requests :)) but that
    >> doesn't work completely cleanly with my all-users install. (Note: I'm
    >> not entirely sure that changing global settings like this to patch a
    >> per-console virtualenv is a good idea, but I'd like to know how hard
    >> it is before dismissing it...)

    >
    >
    > Out of interest, what is the reason forcing you to look at that -
    > bdist_wininst installers?  FWIW, my encounters with virtualenv haven't
    > forced me to hack the registry - I just install bdist_wininst packages into
    > the "parent" Python which isn't ideal but works fine for me.  This was a
    > year or so ago, so the world might have changed since then.


    It's bdist_msi.rather than bdist_wininst.

    I want to avoid putting packages into the "main" Python - at least,
    from my limited experiments the virtual environment doesn't see them
    (I may be wrong about this, I only did a very limited test and I want
    to do some more detailed testing before I decide).

    For bdist_wininst packages, I can install using easy_install - this
    will unpack and install bdist_wininst installers. (I don't actually
    like easy_install that much, but if it works...). But easy_install
    won't deal with MSI installers, and you can't force them to install in
    an unregistered Python. The only way I can think of is to do an "admin
    install" to unpack them, and put the various bits in place manually...

    The other reason for changing the registry is the .py file
    associations. But as I said, I'm not yet convinced that this is a good
    idea in any case...

    Thanks for the help,
    Paul.
    Paul Moore, Feb 2, 2012
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Leny
    Replies:
    3
    Views:
    16,927
    Daniel
    Feb 1, 2005
  2. timw.google
    Replies:
    1
    Views:
    532
    Serge Orlov
    May 11, 2006
  3. Don Bruder
    Replies:
    3
    Views:
    970
    spikeysnack
    Aug 3, 2010
  4. Stefan Ram
    Replies:
    1
    Views:
    397
    Digger
    Sep 13, 2010
  5. Richard
    Replies:
    6
    Views:
    129
    Richard
    Jun 14, 2007
Loading...

Share This Page