Visual Studio Code does not detect Virtual Environments

VS Code: Python Interpreter can't find my venv

The only solution I found was to delete the venv and recreate it. I followed these steps but I’ll provide a brief summary for Windows:

1. Activate your virtualenv. Go to the parent folder where your Virtual Environment is located and run venvscriptsactivate. Keep in mind that the first name "venv" can vary.
2. Create a requirements.txt file. pip freeze requirements.txt
3. deactivate to exit the venv
4. rm venv to delete the venv
5. py -m venv venv to create a new one
6. pip install -r requirements.txt to install the requirements.

This worked for me, I didn’t delete the old, but created a new python -m venv /path/newVenv in the ~/Envs folder, C:UsersAdminEnvs. Maybe VS Code is searching in the ~/Envs folder, or it needs to be added to the python.path in the View -> Command Pallete -> >Preferences: Open User Settings.

1. In VSCode open your command palette — Ctrl+Shift+P by default

2. Look for Python: Select Interpreter

3. In Select Interpreter choose Enter interpreter path... and then Find...

4. Navigate to your venv folder — eg, ~/pyenvs/myenv/ or UsersFooBarPyEnvsMyEnv

5. In the virtual environment folder choose <your-venv-name>/bin/python or <your-venv-name>/bin/python3

The issue is that VSCode’s Python extension by default uses the main python or python3 program while venv effectively creates a "new" python/python3 executable (that is kind of the point of venv) so the extension does not have access to anything (available modules, namespaces, etc) that you have installed through a venv since the venv specific installations are not available to the main Python interpreter (again, this is by design—like how applications installed in a VM are not available to the host OS)

None of the suggestions on this thread worked for me. That said, I don’t think the issue lies with VS Code, it’s venv. I wound up installing PyCharm to fix this. After you’ve downloaded:

PyCharm > Preferences > search “interpreter” > Project: Python Interpreter > Click ‘+’ > in Virtualenv Environment > New environment (should automatically populate everything for a new env). Select OK, OK, OK.

In the bottom left, you’ll see Git | TODO | Problems | Terminal…etc. Click “Terminal” and you should see your environment already activated. From there, pip3 install your dependencies. Close PyCharm.

Go back to VS Code, open your project, and follow the suggestions above to select the Virtualenv (mine was ‘venv’: venv) as your interpreter.

Finally resolved.

If you’re a Linux user, and you’ve used this or similaar to create your virtual environment:

python3 -m venv venv

and you cannot get the debug to work, remove your venv and create it from the VS Code terminal (click Ctrl + back-tick to open).

When you create it from the VS Code terminal, VS Code will ask if you want to use this new environment it amazingly detected for this workspace, say yes.

Part of the confusion here may stem from UI behavior that is at odds with the VScode documentation. The docs state:

When you create a new virtual environment, a prompt will be displayed
to allow you to select it for the workspace.

That didn’t happen in my case (VScode 1.66.2 running on Windows 10 with Remote – WSL plugin version 0.66.2). I followed the steps outlined here; I did not see the pop-up described by the VScode docs but clicking on the Python interpreter version in the status bar showed that VScode had automatically selected the interpreter installed in the virtual environment. Furthermore, I did observe that VScode was sourcing .venv/bin/activate as described in the post linked above

Run the code by clicking the play button, note the .venv and source
“/Users/jemurray/Google
Drive/scripts/personalPython/helloworld/.venv/bin/activate” in the
terminal shows the script is activated and running in the virtual
environment

1.In VSCode open your command palette — Ctrl+Shift+P by default

2.Look for Python: Select Interpreter

3.In Select Interpreter choose Enter interpreter path… and then Find…

4.Locate env folder, open Scripts folder , and choose python or python3

windows – venv

I was having the same error in my scripts with a virtual environment called "venv", so searching the Visual Studio documentation I found that the virtual environment starts with a dot "." but they never mentioned this, then I created my virtual environment ".venv" and that fixes the error:

https://code.visualstudio.com/docs/python/environments#_create-a-virtual-environment

In my own case, I was trying to activate the venv in Windows PowerShell while the venv was created in wsl. So, I had to recreate the venv with PowerShell albeit with different environment name and reinstall the requirements.

Here’s the answer. Add this to your user and/or workspace settings.json file:

"python.defaultInterpreterPath": "${env:VIRTUAL_ENV}".

Then the first time you launch a workspace from an active virtual environment, vscode will set the interpreter correctly. Thereafter it will use whatever interpreter was set the last time the workspace was closed. As long as you don’t manually change it, you’re set. For existing workspaces, just manually set the interpreter and vscode will always use the interpreter from the prior session. It will never use anything in settings.json (or .env or .venv) except the first time a workspace is launched (and in that case, I think it only uses the settings.json name-value pair shown above).

That will work as-is for virtualenvs managed by pyenv-virtualenv (or virtualenvwrapper). Should work for regular virtualenv too. For conda, replace VIRTUAL_ENV with whatever it uses, assuming it sets a similar variable. Just activate something and type env to see all the environment variables.

This is the solution as long as you create a virtualenv, then launch a workspace for the first time, and the association between the workspace and virtualenv does not change. Unfortunately, it appears you have to set the interpreter manually if the association changes, but you only have to do it once.

The official explanation is here, specifically where it says the interpreter is stored internally i.e. not in any configuration file exposed to the user:

This issue in VS code was fixed for me my simply using Command Prompt in VS code instead of PowerShell as the Terminal

"python.venvPath" is the command to provide the venv path.

In VScode settings.json add

  "python.terminal.activateEnvironment": true,

  "python.venvPath": "Add_Venv_DirectoryPath_here",

After some search I found the next property in the vs-code settings which fix the problem for me: Python: Env File, where the default value is ${workspaceFolder}/.env.
Usually I call my venv folder .venv so I fixed the settings to be
${workspaceFolder}/.venv.
Now the venv python version appeared in the select interpreter option.

vs code venv file property

I had a similar problem on my Mac, and found a very easy and simple solution.

I had structured my development folder like this:
Users/my_user_name/Dev/venv.

As I had created multiple virtual environments at the same level on the venv. The problem is I fill out the python.venvPath with Users/my_user_name/Dev/venv1 (or one of the virtual environment.) This prevents VS Code from detecting my other virtual environment. So the fix is very simple. Just change the value of python.venvPath from Users/my_user_name/Dev/venv1 to: Users/my_user_name/Dev/ and voila, it detects all of my virtual environment.

I hope this answer helps whoever having similar problem.

Upgrading to the latest vscode version (1.75.1) solved it for me, on fedora I ran

sudo dnf update code

This triggered re-installation (reload required) and maybe upgrading of the python and jupyter extensions

After the reloads, the python environement in the venv folder was detected again

1. put this in settings.json,

{"python.defaultInterpreterPath":"venv1/Scripts/python.exe",
 "python.terminal.activateEnvironment": true}

2. Run vscode as admin
3. Run "set-executionpolicy remotesigned" in Terminal of vscode
4. Run "venvScriptsactivate" in Terminal of vscode