Wrong python interpreter selected in multiroot workspaces when debugging using ${command:python.interpreterPath}

[gracicot]

Issue Type: Bug

Behaviour

Expected vs. Actual

Expected:

1. Click on the "Debug" green play button from a multi-root workspace
2. The debugger starts normally, and all import statements works.

Actual:

1. Click on the "Debug" green play button from a multi-root workspace
2. The debugger starts, but all import statements for packages installed inside the venv don't work.

Steps to reproduce:

Create a workspace with the following files:

workspace/
  |- python-bug.code-workspace
  |- project1/
  |  |- project1.py
  |- project2/
  |  |- .vscode/
  |  |  |- launch.json
  |  |- project2.py
  |  |- requirements.txt

Here's the content of each files:

python-bug.code-workspace:

{
  "folders": [
    {
      "path": "project1"
    },
    {
      "path": "project2"
    }
  ]
}

project1/project1.py:

print('hello world')

project2/.vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "project2",
      "type": "python",
      "request": "launch",
      "python": "${command:python.interpreterPath}",
      "program": "${workspaceFolder}/project2.py",
      "console": "integratedTerminal"
    }
  ]
}

project2/project2.py:

import pytz
from datetime import datetime
tokyo = pytz.timezone('Asia/Tokyo')
time = datetime.now().astimezone(tokyo).strftime("%Y-%m-%d %H:%M:%S")
print(f"Tokyo time: {time}")

project2/requirements.txt:

pytz==2021.3

1. Open the workspace in VSCode
2. Open an integrated terminal in project2
3. Run python3 -m venv venv in the project2 terminal
4. Run source ./venv/bin/activate in the project2 terminal
5. Run pip install -r requirements.txt
6. Select the python interpreter for project2 to be the one in the venv folder
7. (Sanity check) Run python project2.py in the project2 console, it should run fine
8. (Trigger the issue) Click on the launch button in the debug pane of VSCode, an exception occurs

Workaround

Setting the python interpreter to ${workspaceFolder}/venv/bin/python in launch.json solves the problem, so it seem that the python plugin select the wrong interpreter.

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.8.9
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
• Value of the python.languageServer setting: Pylance

User Settings

defaultLS: {"defaultLSType":"Pylance"}

downloadLanguageServer: true

envFile: "<placeholder>"

venvPath: "<placeholder>"

venvFolders: "<placeholder>"

condaPath: "<placeholder>"

pipenvPath: "<placeholder>"

poetryPath: "<placeholder>"

languageServer: "Pylance"

linting
• enabled: true
• cwd: "<placeholder>"
• Flake8Args: "<placeholder>"
• flake8Enabled: false
• flake8Path: "<placeholder>"
• lintOnSave: true
• banditArgs: "<placeholder>"
• banditEnabled: false
• banditPath: "<placeholder>"
• mypyArgs: "<placeholder>"
• mypyEnabled: false
• mypyPath: "<placeholder>"
• pycodestyleArgs: "<placeholder>"
• pycodestyleEnabled: false
• pycodestylePath: "<placeholder>"
• prospectorArgs: "<placeholder>"
• prospectorEnabled: false
• prospectorPath: "<placeholder>"
• pydocstyleArgs: "<placeholder>"
• pydocstyleEnabled: false
• pydocstylePath: "<placeholder>"
• pylamaArgs: "<placeholder>"
• pylamaEnabled: false
• pylamaPath: "<placeholder>"
• pylintArgs: "<placeholder>"
• pylintPath: "<placeholder>"

sortImports
• args: "<placeholder>"
• path: "<placeholder>"

formatting
• autopep8Args: "<placeholder>"
• autopep8Path: "<placeholder>"
• provider: "black"
• blackArgs: "<placeholder>"
• blackPath: "<placeholder>"
• yapfArgs: "<placeholder>"
• yapfPath: "<placeholder>"

testing
• cwd: "<placeholder>"
• debugPort: 3000
• nosetestArgs: "<placeholder>"
• nosetestsEnabled: undefined
• nosetestPath: "<placeholder>"
• promptToConfigure: true
• pytestArgs: "<placeholder>"
• pytestEnabled: false
• pytestPath: "<placeholder>"
• unittestArgs: "<placeholder>"
• unittestEnabled: false
• autoTestDiscoverOnSaveEnabled: true

terminal
• activateEnvironment: false
• executeInFileDir: "<placeholder>"
• launchArgs: "<placeholder>"

experiments
• enabled: true
• optInto: []
• optOutFrom: []

insidersChannel: "off"

tensorBoard
• logDirectory: "<placeholder>"

Extension version: 2022.0.1814523869
VS Code version: Code 1.64.0 (5554b12acf27056905806867f251c859323ff7e9, 2022-02-03T04:20:17.224Z)
OS version: Darwin x64 20.6.0
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz (8 x 2900)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 3, 3
Memory (System)	16.00GB (0.13GB free)
Process Argv	--crash-reporter-id 2f97d10c-30e9-44a1-ba46-b0cd71465152
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30425749
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
testflightcf:30433671
vsc1dst:30433059
pythonvs932:30410667
wslgetstarted:30433507
vs360cf:30404996
vsrem710:30416614
vscscmwlcmt:30433761

[kimadeline]

Hi @gracicot, thank you for reaching out.

You shouldn't have to specify the python line in your launch.json config, if the virtual environment is selected for that specific folder it should get picked up automatically. ${command:python.interpreterPath} is also an incorrect value.

What happens if you remove the python line from your launch.json config?

[gracicot]

@kimadeline Seems like it's working without the python line. Strangely, the value ${command:python.interpreterPath} works very well with a single root workspace. Thanks for pointing out the problem. I'm just unsure how I'm wrong. The python extension allows us to select the python interpreter from the status bar, I figured I had to choose that interpreter to be in line with what's displayed in the editor.

[kimadeline]

After digging deeper in the code, we do support ${command:python.interpreterPath}. However, when using it we make an assumption that there will be a workspaceFolder argument with the path to the workspace folder, and use that to determine the correct Python path:

vscode-python/src/client/debugger/extension/configuration/launch.json/interpreterPathCommand.ts

Lines 30 to 42 in 33476c4

	public _getSelectedInterpreterPath(args: { workspaceFolder: string } | string[]): string {
	// If `launch.json` is launching this command, `args.workspaceFolder` carries the workspaceFolder
	// If `tasks.json` is launching this command, `args[1]` carries the workspaceFolder
	const workspaceFolder = 'workspaceFolder' in args ? args.workspaceFolder : args[1] ? args[1] : undefined;
	let workspaceFolderUri;
	try {
	workspaceFolderUri = workspaceFolder ? Uri.parse(workspaceFolder) : undefined;
	} catch (ex) {
	workspaceFolderUri = undefined;
	}
	return this.configurationService.getSettings(workspaceFolderUri).pythonPath;
	}

This assumption is incorrect, since this argument isn't there. This will result in us trying to get the first Python path we can get our hands on (because of the undefined value), which is fine in single-workspace scenarios, but, as you noticed, doesn't work so well for multi-root workspaces.

tl;dr: It's a bug on our end, thank you for reporting it!

[lig]

@kimadeline I've been facing this really hard recently. A multi-root workspace keeps using an interpreter defined for the first folder instead of the correct one.

Bounty opportunity: I'm ready to pay €20 for this to be fixed.

[kimadeline]

I'm not on the Python team anymore, but I'll let them know that it's an acute pain point for you 🙂

[karrtikr]

@lig https:/microsoft/vscode-python/suites/15205238033/artifacts/868956057 fixes the issue described in #18482 (comment), try installing it using Install from VSIX command and see if it helps.

[lig]

@karrtikr No effect, sorry. I needed to install code-insiders and I've checked that Python v2023.15.5895828483-dev extension is installed.

It looks like it uses a venv defined in the first folder for anything unconditionally now ignoring any folder specific interpreter configuration.

[karrtikr]

I see, the cause stated in #18482 (comment) should be fixed, it's likely that there's another bug in addition to that. As a workaround try removing

"python": "${command:python.interpreterPath}",

in your launch.json from all workspace folders, let me know if that helps.

[lig]

I have only one launch.json file and it doesn't have python key.

[lig]

So, now it always uses the first folder's venv for everything except stdlib packages. Using "go to definition" on stdlib packages results in opening a file from system default interpreters' library.

I think I can share my entire workspace with you as it contains only Open Source projects at the moment.

[lig]

Or maybe some logs would be enough?

[karrtikr]

This issue is related to ${command:python.interpreterPath}, if you don't have "python" set, maybe your issue is different and you're not referencing this command at all? In that case please open a new issue using Python: Report Issue command and we'll be happy to have a look.

Btw note you need to create separate launch.json for each workspace folder if you wish to use selected interpreter for each folder:

Each launch.json will only be run using the folder's selected interpreter in which that launch.json file exists.

[karrtikr]

I believe the original issue #18482 (comment) should be fixed with #21835, hence I'm closing this. If it isn't please let us know and we'll be happy to have a look again.