Virtualenv: VSCode Powershell can not auto activate env (virtualenv 16.7.2)

[kalozoya-gregal]

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.

[gaborbernat]

@joaoe regression here introduced by https://github.com/pypa/virtualenv/pull/1388, any ideas?

[pfmoore]

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 :-(

[pfmoore]

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?

[kalozoya-gregal]

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.

[joaoe]

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.

[pfmoore]

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]

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

[kalozoya-gregal]

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]

virtualenv==16.7.3 has the same issue.

[pfmoore]

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.

[gaborbernat]

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

[gaborbernat]

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

[joaoe]

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

[pfmoore]

@joaoe No problem :-)