Registry entries set up by the Windows installer
p.f.moore at gmail.com
Thu Feb 2 09:09:55 CET 2012
On 2 February 2012 00:28, Mark Hammond <skippy.hammond at gmail.com> 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,
More information about the Python-list