Registry entries set up by the Windows installer

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.

On 2/02/2012 2:09 AM, Paul Moore 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.


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


Yep, I think that is correct.


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


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

On 2 February 2012 00:28, Mark Hammond <skippy.hammond@gmail.com> wrote:
[...]

Thanks for the information.


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


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.