Activating an environment fails because running powershell scripts is disabled by default on Windows

[qubitron]

Environment data

• VS Code version: 1.27.1 (user setup)
• Extension version (available under the Extensions sidebar): 2018.8.0
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.7..0
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: N/A

Actual behavior

Creating a new terminal in a fresh Windows install results in a powershell error

PS C:\dev\loadtest> & c:/dev/loadtest/env/Scripts/activate.ps1
& : File C:\dev\loadtest\env\Scripts\activate.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:3
+ & c:/dev/loadtest/env/Scripts/activate.ps1
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Expected behavior

I don't need need to disable running scripts in able to use VS code

Steps to reproduce:

1. Fresh install of windows
2. install python
3. create virtual environment
4. try to activate it in VS Code

[d3r3kk]

Hmmm.. this feels like it might be a VSCode problem.

To fix the issue, you can simply open a Powershell window as administrator and type the following:

Set-ExecutionPolicy RemoteSigned

And hit enter, respond y to any prompts that appear.

[d3r3kk]

I take it back - we are running an activate.ps1 file from a .venv!

Hmmm... not sure what we can do about this from the extension's perspective. Don Jayamanne (@DonJayamanne) can we inject some powershell code prior to running activate.ps1 when we launch a python terminal?

[DonJayamanne]

can we inject some powershell code prior to running activate.ps1 when we launch a python terminal?

Yes we can.
Changing the label, as this isn't a bug. we're trying to improve the UX for users of the extension.

Derek Keeler (@d3r3kk)
Your original suggestion works, changing the policy will work, however Dan Taylor (@qubitron) doesn't want to have to do it manually.
Basically we should do what ever we can to remove/reduce such road blocks.

[d3r3kk]

Yep, that's pretty standard Powershell behaviour/expected workflow on a new machine. Not sure we should usurp that is what I'm getting at.

However, if we choose to do so, it shouldn't be too difficult to put a quick popup and ask the user if doing so will be ok with them first (much like the powershell cmdlet Set-ExecutionPolicy does).

[DonJayamanne]

However, if we choose to do so, it shouldn't be too difficult to put a quick popup and ask the user if

Agreed.
After all, we're executing some script that we have no control over.

Dan Taylor (@qubitron) thoughts

[qubitron]

1. This will require elevation to set the execution policy correct? Not all users have admin rights on the system
2. What if the user doesn't want this execution policy set for security reasons, it's off by default for a reason?

Why do we even need powershell cmdlet to do this, why can't we run a batch file or something else that doesn't require admin privileges/execution policies to be set?

[brettcannon]

It's a PowerShell script because that's how you get the prompt updated to list the virtual environment's name: https://github.com/python/cpython/blob/master/Lib/venv/scripts/nt/Activate.ps1

[brettcannon]

The other option any notification could have is offer to switch off the automatic activation on top of providing instructions on how to change the policy.

[qubitron]

OK, so really this is an issue because we're using a powershell cmd prompt instead of CMD (which is what I use outside of VS Code and just lets me activate without having to set any policies).

Since I assume we can't change the default from powershell to cmd, detecting the issue and prompting users to set the execution policy (with a button) seems like the right solution.