Pull requests

#2 Open
Repository
codito codito
Branch
default
Repository
guillermooo guillermooo
Branch
default

Fix for issue #8

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update 
hg pull -r default https://bitbucket.org/codito/virtualenvwrapper-powershell
Author
  1. Arun Mahapatra
Reviewers
Description

Updated logic for reading InstallPath and PythonPath registry variables. Added support for both system-wide and per-user python installation. Activate and Deactivate functions now backup/restore PYTHONHOME environment variable

Comments (7)

    1. Arun Mahapatra author

      Or would it be a good idea to replace registry based mechanism and rely on PYTHONHOME, PYTHONPATH variables? Not sure if there could be issues when someone wants to modify these variables in Pre/Post hooks.

      This could also solve one problem with registry based mechanism - while I'm in a virtualenv, I cannot use the system-installed python in a separate console or run any other python app outside virtualenv.

  1. guillermooo repo owner

    I'm starting to lose my patience with Bitbucket issues... It's a mess to try to follow a conversation.

    I think I've lost the overview of this patch, so allow me to summarize the situation and please correct me if I am wrong:

    At any give point, only one Python install can be "active" on the user's machine. This install can be either a per-user install or a system-wide install.

    Per-user install

    Everything works fine without the patch with the current code, right? (This is not true, because some installers don't create the referenced keys in the registry, at least in my experience, but this is a different problem.)

    System-wide install

    HKLM/Software and children thereof are redirected keys, so Wow6432Node comes into play. We shouldn't access that key directly, because it might break compatibility down the road.

    Now, what can we do about system-wide installs? If we attempted to access the HKLM hive, we'd need admin rights, wouldn't we?

    1. Arun Mahapatra author

      Your summary is correct. Access HKLM\Software will require admin privileges. In case of 32bit system-wide installs, we should check for elevated powershell and throw an error.

      1. guillermooo repo owner

        Assuming a system-wide install, what's the benefit of modifying the HKLM registtry? A few observations:

        1) The user needs elevation

        How can we achieve this? Opening a new instance of PS as admin? Restoring the registry after that would be difficult; if the user simply closed the console, we'd have to keep some state to remember to change the registry the next time. It looks complicated.

        2) Can we limit ourselves to the HKCU hive?

        Even if are facing a system-wide install, wouldn't it work to just change the HKLU hive entries instead? Maybe Python checks HKCU and HKLM in order. It doesn't really have any other information to determine what kind of install it is, right? In such a case, the check to change venvs would go like this:

            a) Change HKCU
            b) Done
        

        To restore the entries, we'd do this:

            a) Is there any Python-releated entry in HKLM?
               a.YES and we're restoring, not changing venvs) Delete HKCU entries
               a.NO) Change HKCU only
            b) Done
        

        If it proved to work, this would be my preferred approach.

        3) If the above fails, we could resort to calling reg.exe with elevation from the same VirtualenvWrapper instance, without having to start a new one.

        Thoughts?

        1. Arun Mahapatra author

          I did a small experiment. Removed the python related HKCU and HKLU registry keys. In a non-virtualenv shell, ran python.exe from c:\python27 and \.virtualenvs\venv\scripts\. In both cases, python picked up the correct sys.path: for venv case it picked up the Lib & DLLs from \.virtualenvs\venv.

          It means python.exe doesn't read the registry keys, it's only the installers who read it. All we need to ensure is that the correct python.exe runs for an user.

          However the other installers (like pywin32 or pyside, for instance) read the registry to know where python is. They also provide user an option to choose python install directory in the installation wizard. So our modification of registry is just providing a value-add for additional installers that user may use.

          I believe most of us who use virtualenv, use pip for package management. In that case, can we just inform the user (for a non-admin shell and system-wide install) that installation of other software functionality will not be available for virtualenv?