Vscode-python: venv not working for custom location (after vscode restart)

Created on 4 Nov 2020  路  7Comments  路  Source: microsoft/vscode-python

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

  1. create a new workspace
  2. create and select a venv in a custom location
  3. verify that venv is used correctly by VSCode
  4. close and reopen VSCode
  5. 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?

triage type-bug

All 7 comments

Thanks for the bug report! We investigate issues in order based on priority and severity, which includes the impact it has on your ability to use the extension to do productive work, and the number of people affected. If other users come forward and leave a comment demonstrating they are seeing/reproducing the problem then we will raise this issue's priority.

If you think your issue is more of a question or configuration problem rather than a bug, please ask on Stack Overflow with the visual-studio-code and python labels for help.

Thanks for your understanding and patience!

I responded over in https://github.com/microsoft/vscode-python/issues/14592#issuecomment-721904124 before seeing this issue. It makes me completely unable to work with any other environment than the one I happened to have selected when I became unable to change it. I guess one could theoretically wipe the environment clean and repopulate it every time one wants to work on some other project, but that is not really feasible. I'd say it severely hampers the capacity to use VSC productively for those affected.

Manually switching do a different environment via conda activate other-env doesn't seem to work for me, by the way. Probably because VSC calls python.exe directly. So yeah, not fun.

Hello Silun!

As I haver stated in my update - It seems that I am actually able to use the venv without problems. The only problem, which remains from this issue for me, is that the status bar does not show that the interpreter is part of a venv(after restarting VSCode). This creates the impression, that you are unable to change the venv - but the integrated terminal, as well as code execution use the correct configured venv interpreter.

You description(here and in https://github.com/microsoft/vscode-python/issues/14592#issuecomment-721904124) suggests that you are probably facing a problem which I had previously, which was caused by a 'damaged' venv.

Did you move your venv to a different location on your file system after creating it? Can you verify that your virtual environment is actually working by activating it in your systems terminal and confirming that it is actually used(e.g. checking the the installed packages)?

I have not moved the venv at all. I can use all my venvs just fine in windows terminal via conda activate venv-name, it shows the (venv-name) in front of the line, and conda list gives the correct packages. I can enter and leave my environments just like I should, it's only VSC that is acting up.

Edit: Okay, this is a surprise. There was a doubled pythonpath line in one of the settings files and switching the environments would only change the first occurence, not the second, thus getting stuck in the one environment. That seems like unintended behavior but would be a different issue altogether.

@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!

@Silun The issue you face is dup of Closed as dup of https://github.com/microsoft/vscode-python/issues/14645

Was this page helpful?
0 / 5 - 0 ratings