Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Registry entries set up by the Windows installer

Reply
Thread Tools

Registry entries set up by the Windows installer

 
 
Paul Moore
Guest
Posts: n/a
 
      02-01-2012
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.
 
Reply With Quote
 
 
 
 
Mark Hammond
Guest
Posts: n/a
 
      02-02-2012
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
 
Reply With Quote
 
 
 
 
Paul Moore
Guest
Posts: n/a
 
      02-02-2012
On 2 February 2012 00:28, Mark Hammond <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[JDK7]Java's many registry entries under Windows Stefan Ram Java 1 09-13-2010 05:33 AM
Picking X random entries from linked list of Y entries Don Bruder C Programming 3 08-03-2010 09:10 AM
Finding entries in Windows Registry matching a RE Richard Ruby 6 06-14-2007 02:02 AM
can distutils windows installer invoke another distutils windows installer timw.google Python 1 05-11-2006 10:07 PM
Tying up Port Login table entries with Port Table Entries in CISCO SNMP John Ramsden Cisco 0 07-24-2004 04:03 PM



Advertisments