# VSCode Powershell can not auto activate env (virtualenv 16.7.2) #1398

Open
opened this issue Aug 2, 2019 · 14 comments

## Stack:

• Windows 10 1903
• VSCode v1.36.1
• Python 3.5
• virtualenv 16.7.2

## Problem

VSCode when I use a pythonPath that is a virtualenv, if open a terminal, automaticaly use the 'activate.ps1' script with this command:
& c:/Users/path/to/env/.pythonenv/Scripts/activate.ps1
but i have this error:
You must 'source' this script: PS> . &

I know that is necesary dot (. c:/Users/path/to/env/.pythonenv/Scripts/activate.ps1), but if I use & . c:/Users/path/to/env/.pythonenv/Scripts/activate.ps1 give error:

& : El término '.' no se reconoce como nombre de un cmdlet, función, archivo de script o programa ejecutable.

If comment this lines on activate.ps1, i can use the terminal normaly:

if (@($null,"Internal") -notcontains$myinvocation.commandorigin) {
Write-Host -Foreground red "You must 'source' this script: PS> . $($myinvocation.invocationname)"
exit 33
}


## Expected behaviour

PS C:\Users\path\to\project> & c:/Users/path/to/env/.pythonenv/Scripts/activate.ps1
(.pythonenv) PS C:\Users\path\to\project>


There is some what I can do without modify 'activate.ps1'?
Thanks.

Contributor

### gaborbernat commented Aug 2, 2019

 @joaoe regression here introduced by #1388, any ideas?
Member

### pfmoore commented Aug 2, 2019

 Looking at #1388, when did it become necessary to "source" activate.ps1? The Powershell activate script has traditionally been runnable without needing to "source" it (unlike the Unix scripts). If this has changed (and it's been a while since I checked as I don't use the "activate" scripts much) then that's quite a significant regression :-(
Member

### pfmoore commented Aug 2, 2019

 Note: I see nothing in #1388 that changes activate.ps1 to need sourcing, it just seems to blindly assume that it's required and error if the user has run the file directly. Maybe the simple solution is just to revert the Powershell-related changes in #1388 as they aren't needed?
Author

### kalozoya-gregal commented Aug 2, 2019

 Looking at #1388, when did it become necessary to "source" activate.ps1? The Powershell activate script has traditionally been runnable without needing to "source" it (unlike the Unix scripts). If this has changed (and it's been a while since I checked as I don't use the "activate" scripts much) then that's quite a significant regression :-( It seems that only wants writing resembles what happens in Unix, even without being necessary. I am working with these commented lines and for now there is no problem. If it is not necessary for something more internally, I would ask for a regression of #1388 . At least in the files that do not need "source" or something like that.
Contributor

### joaoe commented Aug 2, 2019 • edited

 Hi. I just tested and indeed the ps1 script can be run locally, and not only sourced. I recall trying to run it without effect, but I guess my memory is failing me and perhaps that was another shell. Running the scripts directly is something for which there is very little testing. I can make a PR later today or tomorrow. Sorry for the trouble.
Member

### pfmoore commented Aug 2, 2019

 Cool. Sounds like it was simply a misunderstanding of the differences between the Unix and Windows scripts. For future reference, the Windows scripts (bat and ps1) should simply be run from the prompt like any other command, there's no need for using "source". This is (sort of) documented here - but mostly "by omission", there's no mention of using "source" for the Windows scripts so you can assume it's not needed. That assumption is probably not at all obvious to someone more familiar with POSIX than with Windows :-( Historically, none of this was tested much (if at all).

### Ssssix40 commented Aug 19, 2019

 hey i just install virtualenv==16.6.2 , and fix it. try it if you don't need the latest version. (i know it's a stupid way but it's really useful
Author

### kalozoya-gregal commented Aug 22, 2019

 hey i just install virtualenv==16.6.2 , and fix it. try it if you don't need the latest version. (i know it's a stupid way but it's really useful I know. For now, i have those version, but the problem is that it is incorrect behavior with ps1 files. @Ssssix40

### hamaney commented Aug 23, 2019

 virtualenv==16.7.3 has the same issue.
Member

### pfmoore commented Aug 23, 2019 • edited

 I created #1408 with a fix. @gaborbernat and/or @joaoe can you take a look at that, please? There's something that went wrong in the tox -e embed run, so I'm not 100% sure the PR is correct. If you have concerns, feel free to create a replacement PR with the embedding redone. Edit: Never mind, @gaborbernat explained the behaviour over on the PR, and has merged it.
Contributor

### gaborbernat commented Aug 23, 2019

 release going out with #1410 via https://dev.azure.com/pypa/virtualenv/_build/results?buildId=11571
Contributor

### gaborbernat commented Aug 23, 2019

 available under https://pypi.org/project/virtualenv/16.7.4/
Contributor

### joaoe commented Aug 23, 2019

 Hi. I'm away from home and my computer so I could not look at this issue. Thank you for your fix :)
Member

### pfmoore commented Aug 23, 2019

 @joaoe No problem :-)