venv not working for custom location (after vscode restart)
See original GitHub issueEnvironment data
- VS Code version: 1.50.1
- Extension version (available under the Extensions sidebar): v2020.10.332292344
- OS and version: Win7 x64
- Python version (& distribution if applicable, e.g. Anaconda): 3.8
- Type of virtual environment used (N/A | venv | virtualenv | conda | …): venv
- Relevant/affected Python packages and their versions: XXX
- Relevant/affected Python-related VS Code extensions and their versions: XXX
- Value of the
python.languageServer
setting: XXX
Expected behaviour
After pointing ‘Python: Select Interpreter’ to a custom location(e.g. ‘C:\VENVs\venv1’), the virtual environment is used for the current workspace, which is indicated in the status bar. Closing VSCode and reopening it, should not break this behavior.
Actual behaviour
The venv in the custom location is used correctly the first time it is added to VSCode. After VSCode is closed and reopened again, the venv is non functional inside VSCode. It is correctly configured in the workspace’s settings.json. The statusbar shows the correct path while hoovering over the current interpreter, but the status bar caption is missing the indicator that this is a venv.
Opening an integrated terminal shows the (venv1) prefix, but the venv is not loaded correctly(e.g. python command is missing, because path to venv executable is not loaded). Furthermore installed packages are missing, which clearly indicates that the wrong interpreter is being used.
After making an venv unusable ‘buggy’(by adding it, closing and reopening VSCode) it will show this behavior even for a different workspace, where it hasn’t been selected previously at all.
Update regarding behavior
At first it seemed that the configured venv is also not used at all, but I noticed that this was actually my mistake(I wasn’t aware that moving a venv breaks its function in general, because absolute paths are hardcoded in its internal scripts).
Therefore the update: The configured interpreter seems to be used correctly by VSCode, but after closing and reopening VSCode, the sufix in the status bar, e.g.: ‘(venv: myvenv)’ is missing. This has been obeserved not only for the broken venv, but also for new created venvs.
Steps to reproduce:
- create a new workspace
- create and select a venv in a custom location
- verify that venv is used correctly by VSCode
- close and reopen VSCode
- observe broken behavior of previously selected workspace
Notes
I currently don’t have the ressources to analyze this in detail - what I have seen so far:
After adding the python interpreter for the first time it gets added to the SQLite database in the configuration folder User\globalStorage\state.vscdb under the key ms-python.python. I haven’t tried to tinker with the entries manually, but it is probably related to the existence of this entry?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:8
Top GitHub Comments
@Silun The issue you face is dup of Closed as dup of https://github.com/microsoft/vscode-python/issues/14645
@Silun I think your issue is different from the one @dmi-github stated, but it’s dup of the other issue I’m investigating, would greatly appreciate your help there. Can you please fill the issue template and link more details in a comment there: https://github.com/microsoft/vscode-python/issues/14645
I’m especially interested in the last edit comment your left about “double pythonpath”, please elaborate and leave a comment there, thanks!