Flask Environment Setup for windows

Hello,
in “Build Python Web Apps with Flask” path,
in “4. Introduction to Flask” chapter,
in “Jinja2 Templates and Forms” section,
there is a video check point “Flask Environment Setup”.
(https://youtu.be/O0gcAh-cRvw?t=230)

And at 3:50 the author is explaining how to activate the virtual environment for windows.
He says that you only need to type “Scripts\activate.bat” in your terminal to activate your virtual env.

So here is the question: how can i check if i am in the correct virtual env?

Because previously in mac after activation we could see it as here, with “(myapp)”:

But in windows there is nothing we can see.

Thank you!

Edit: Apologies edited my post instead of sending a reply. Put this back together for easier viewing.

What kind of terminal are you running? The basic command prompt? GitBash? The only time I’ve used activate.bat is for the basic cmd shell (powershell works with just activate).

Edit: Made a mistake here, you can get away with sourcing activate with powershell but the actual file you want to be using is activate.ps1. To correctly source it (run it and update variables within the current shell, not a new shell) the command should be something along the following lines; note that the initial dot is necessary-

. .env/Scripts/activate.ps1

The activate script normally adds the name of the current environment to the basic prompt but if your prompt is customised in some way then it might not be altered correctly (you may then want to add it to the custom prompt).

If you check the contents of the activate/activate.bat scripts then you can see exactly what modifications they make to your environment variables (e.g. VIRTUAL_ENV) so you could check your current environment without the prompt.

2 Likes

I’m using “powershell” i suppose.

–“you may then want to add it to the custom prompt”
How do i do that?

The only things i could notice that seem to me to be important are:

  1. from previous img this excerpt:


    i suppose it tells us that we couldn’t use it outside the GitBash.

  2. and this line of code with that variable VIRTUAL_ENV:

Are you talking about that? To identify a different type of virtual environment by the address?

UPD: And also, of course, when i use just activate or Scripts\activate it would show the errors:

I’d suggest a web search for that particular error, vs code and powershell since it looks like simple permissions fix.

I’d also highly suggest going through the vs code docs which covers the basic set-up-

3 Likes

Have you tried it in a Powershell window outside the VS Code integrated terminal? I think this is an issue that is specifically related to how VS Code and Powershell interact.

In a normal Powershell terminal, typing Scripts/activate from inside your myapp directory should do it just fine. If that works, then it’s definitely connected to VS Code, and is probably this known issue:

It looks like a few people found and posted a workaround in that issue :point_up_2: so you can try that. Or, you can just switch your VS Code integrated terminal over to cmd or whatever your preferred terminal is.

It is worth noting, however, that VS Code had already recognized and activated your virtual environment:
image

It is just the integrated powershell prompt that wasn’t working correctly.

3 Likes

Ahh, good catch on the activation. There’s suprisingly little information about this despite the fact it seems to default to powershell these days.

For anyone else viewing this it’s worth noting that vs code has a lot of automation when it comes to virtual environments. It’s always best to check the docs in this case to ensure you’re working in the correct envionment and don’t realy on the prompt. The envrionments page on the vs code docs (linked above) very specifically mentions how to deal with this potential error (long term).

* As an additional fix the powershell script appears to default to having a capital at the start of the file name == Activate.ps1 so if you’re running in the shell prompt as opposed to using the VS Code set-up avoid copy-pasting (or at least make certain of the local names).

1 Like

For what it’s worth, this might even be solve-able with two clicks inside VS Code itself.

As we see in the screenshot, VS Code detected the virtual environment and activated it for the editor.
If the integrated terminal was already open before VS Code activated the environment, it probably wouldn’t update the terminal. BUT, usually it will if you open a new terminal.

For example, in the screenshot below, you can see I have a VS Code terminal open with Powershell, but it doesn’t show the activated environment. The editor has already activated the environment though (see bottom left).

To update this in the terminal I just hit the trashcan icon in the top right of the terminal (where the red arrow is). This will kill the current terminal instance.

Then, just go to Terminal -> New Terminal in the top task bar of VS Code (or hit Ctrl + Shift + ` to open a new terminal) and then VS Code automatically activates the environment inside the terminal for you.

As you can see in the screenshot below, VS Code opened the terminal in the appropriate folder and activated the environment for me after I hit the trashcan button and opened a new terminal.

2 Likes

Yes, thank you!
The workaround worked just fine.
Now it can be activated by “scripts/activate”.
@tgrtim, yes, it seems like some bug regarding the relationship between PowerShell and VSCode and their permissions.
My issue was resolved by the next chunk of code typed in the PowerShell terminal:

PS D:\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

And the link to that answer:
(Activating an environment fails because running powershell scripts is disabled by default on Windows · Issue #2559 · microsoft/vscode-python · GitHub)

Yes, after fixing, it works as you’ve described.
But previously i couldn’t do that (