"workon" command has no effect after second call
Opened this issue · 4 comments
my system: windows 10:
> [System.Environment]::OSVersion.Version
Major Minor Build Revision
----- ----- ----- --------
10 0 19041 0
powershell version: Version : 5.1.19041.1023
I use pyenv-win to install: 3.8.10
And put the "VirtualEnvWrapper.psm1" at: "$mydocuments\WindowsPowerShell\Modules".
Added these to Profile.ps1:
$PowerShellPath = Split-Path $PROFILE.CurrentUserAllHosts
Import-Module $PowerShellPath\Modules\VirtualEnvWrapper.psm1
Restarted powershell, execute mkvirtualenv t1, I can enter (t1) virtualenv.
then execute deactivate, virtualenv is deactivated, all is good.
Then I type workon t1 again, prompt does not have (t1) prefix, and the python command is still the global one, at this point, if I execute deactivate, this is reported as not recognized.
I have to edit the VirtualEnvWrapper.psm1:
In the function function Workon, change this line:
Import-Module $activate_path
To this:
& $activate_path
Now everything works, I can workon t1, deactivate, workon t1, all is good.
Just don't know the root cause, I'm completely noob with powershell.
Having to use the call operator suggests that a change of scope has occurred. What directory is your 'Envs' directory stored in?
I'm getting different behavior for PS 7 and PS 5 depending on whether I invoke them in Windows Terminal or standalone. Location of 'Envs' is one of them.
I did not put any explicit environment to change the "Envs", it's at: $env:USERPROFILE/Envs
But I do have a "HOME" env var globally, which points to a subdirectory of $env:USERPROFILE, and in powershell, there is a $home variable pointing to $env:USERPROFILE, not sure if this can be the root cause.
you can also just use the same activation as in mkvirtualenv at line 103ff:
$VEnvScritpsPath = Join-Path $NewEnv "Scripts"
$ActivatepPath = Join-Path $VEnvScritpsPath "activate.ps1"
. $ActivatepPathThe Import-Module fct only executes once per shell session apparently.