Hi!
Whenever I switch venvs, I have a script that modifies my HKCU/
Software/PythonCore to point to the new active environment. Most
python installers pick this setting up and successfully install
themselves in the virtualenv. However, wxPython doesn't seem to honor
it. Is there a way around this?
Regards,
Guillermo
Do you also have the Python registry keys under HKLM? That is where the installer looks first, and then if there is not a matching set of keys for the associated python version for then it looks under HKCU.
http://trac.wxwidgets.org/browser/wxPython/trunk/distrib/make_installer.py#L344
On 11/9/10 12:04 PM, guillermooo wrote:
Hi!
Whenever I switch venvs, I have a script that modifies my HKCU/
Software/PythonCore to point to the new active environment. Most
python installers pick this setting up and successfully install
themselves in the virtualenv. However, wxPython doesn't seem to honor
it. Is there a way around this?
--
Robin Dunn
Software Craftsman
Do you also have the Python registry keys under HKLM? That is where the
installer looks first, and then if there is not a matching set of keys
for the associated python version for then it looks under HKCU.
I do, and that's the root of the problem. HKLM can only be modified by
an admin account, so it makes sense that the priority in the installer
code would be reversed. There doesn't seem to be able any guideline on
the recommended order of precedence for registry lookups--or I've
failed to find it--but file types in HKCU do shadow those in HKLM, for
instance.
Also, the WOW6432 node should not be accessed directly, although this
is another issue:
Do you also have the Python registry keys under HKLM? That is where the
installer looks first, and then if there is not a matching set of keys
for the associated python version for then it looks under HKCU.I do, and that's the root of the problem. HKLM can only be modified by
an admin account, so it makes sense that the priority in the installer
code would be reversed. There doesn't seem to be able any guideline on
the recommended order of precedence for registry lookups--or I've
failed to find it--but file types in HKCU do shadow those in HKLM, for
instance.
I agree that makes sense.
Also, the WOW6432 node should not be accessed directly, although this
is another issue:
IIRC this was needed on 64-bit XP because the installer is a 32-bit app so we need to access the redirected key values directly in order to find the right ones, or something like that. I think the newer versions of Windows do the right thing and a match will be found using the earlier tests.
On 11/9/10 3:45 PM, guillermooo wrote:
--
Robin Dunn
Software Craftsman
> Also, the WOW6432 node should not be accessed directly, although this
> is another issue:>Registry Redirector - Win32 apps
IIRC this was needed on 64-bit XP because the installer is a 32-bit app
so we need to access the redirected key values directly in order to find
the right ones, or something like that. I think the newer versions of
Windows do the right thing and a match will be found using the earlier
tests.
Apparently, WinXP does support accessing the alternate views vía flags
already:
Accessing an Alternate Registry View - Win32 apps | Microsoft Learn