Registry entries set up by the Windows installer

[Paul Moore]

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.

 

[Mark Hammond]

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

 

[Paul Moore]

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.

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.

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.