Ask questionspython.defaultInterpreterPath doesn't always work (plus feedback/concerns about DeprecatePythonPath experiment)


After finding myself one of the 4% opted into the DeprecatePythonPath experiment, I've noticed some inconsistency in how the interpreter path is handled, and believe there is buggy behavior in how python.defaultInterpreterPath is implemented. The replication is as follows:

  • Clear out your local storage so you start fresh
  • Set python.defaultInterpreterPath to your preferred python path (e.g. a local pyenv installation of 3.7.2)
  • Load up your project and notice that it detects the interpreter path properly
  • Exit vscode
  • Delete your python install and install a new one, simulating an upgrade (e.g. 3.7.4)
  • Don't forget to update python.defaultInterpreterPath to point to the new interpreter path
  • Reopen vscode and load up your project

Actual results:

vscode has now detected that the interpreter it had been using is no longer available, and is now in a state where there is no interpreter configured, and a user has to manually specify one.

Expected results:

vscode should detect that the cached state of the interpreter is incorrect (which it seems to do) but instead of "prompting" (it's hardly a "prompt") the user to select a new interpreter, it should fall back to the configured python.defaultInterpreterPath (after all, that's what a default is for).


  • If you run this and choose not to fully delete the original python version, vscode will happily continue to use this old version instead of the one the project maintainers would prefer to enforce (see below for justification and use case).
  • python envs installed in these subdirectories are not detected by vscode's picker and do not always show up with autocompletion so I had to manually type out (copy/paste) the entire path in order to use it (this seems to have improved after wiping my local storage cache directories, but is still annoying).

Other thoughts

I work on a team that uses direnv to enforce a specific environment for each of our projects. This includes maintaining different versions of python in the project directories based on where these will be deployed (e.g. App Engine has access to 3.8 but App Engine Flex only 3.7.2), and allowing us to rebuild these environments on the fly, test out different versions on different branches (e.g. when Flex gets 3.8 we'll make a branch to test that but still need to switch back and forth to work on "known stable" branches).

Since it seems likely from comments on #2125 that this experiment will become permanent, my initial solution to both of these was to add something the following to the shared settings.json files in each repository to ensure that everyone is opted in to this experiment and will default to the proper python instance:

  "python.experiments.optInto": ["DeprecatePythonPath - experiment"],
  "python.defaultInterpreterPath": "${workspaceFolder}/.direnv/python-3.7.2/bin/python3",
  // ...

However, due to the aforementioned bug, this means that many of our projects open up the "first" time with no interpreter set (seemingly conflicting with whatever value was cached before the experiment was activated), and that any attempts to upgrade or switch python interpreters for a specific project will mean the user has to manually specify the python interpreter every time he/she switches between branches with different python versions activated (and know which version to select, which means cracking open settings.json or our .envrc to see). This is not an improvement as far as usability goes.

So for now, I've opted my team out of this experiment (thanks for adding that option) until the usability issues have been resolved, and/or there are options that once again allow for project settings to control the python path:

  "python.experiments. optOutFrom": ["DeprecatePythonPath - experiment"],
  "python.pythonPath": "${workspaceFolder}/.direnv/python-3.7.2/bin/python3",
  // ...

Answer questions karrtikr

Yes... Granted, part of this is confusion around the experiment info page I was sent to when vscode notified me

Yes, apologies for the confusion. The previous wiki wasn't clear enough about the details, I recently mended it.

But you keep answering me as if I'm not specifically reporting it as a bug

I wanted to first clear up the first part where you mentioned you "believe there is buggy behavior in how python.defaultInterpreterPath is implemented", and then get to your other thoughts section (which is a very valuable feedback, thanks for that).

We realize that the new experiment would take away the ability to share interpreter paths in workspace settings, which is why I wasn't talking about it like it's a bug because the behavior you see is expected from dev-perspective. If interested, you can have a look at the few issues which motivated this solution.

We have marked this issue as "needs decision" to make sure we have a conversation about your thoughts, after which we'll get back to you.


Related questions

Auto Scroll in the Jupyter output hot 3
Workspace contains pipfile but pipenv --venv failed hot 2
Can you turn off the Microsoft Python Language Server? hot 2
Unable to debug Python tests (duplicate entries in "env") hot 2
Jupyter server crashed. Unable to connect. Cannot assign requested address hot 2
Auto Scroll in the Jupyter output hot 2
Unable to run launch targets with newest VS Code Python extension hot 2
Unable to start jupyter python interactive window hot 1
HBox output is not shown correctly in the interactive window hot 1
Debug -> Add Debug Configuration 'Cannot read property openConfigFile' hot 1
VSCode cannot connect to jupyter server; with browser this works fine hot 1
Linux arm64/aarch64 support hot 1
Add setting to disable icon for "Run Python File In Terminal" hot 1
Extension Host keeps crashing hot 1
Activate environment before debugging tests hot 1
Github User Rank List