GetInterpreterList does not pick up newly added virtual environments (when called from Jupyter)

[rchiodo]

Environment data

• VS Code version: Insiders latest
• Extension version 2021.10.1258668113-dev
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): XXX
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): XXX
• 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

[NOTE: If you suspect that your issue is related to the Microsoft Python Language Server (python.languageServer: 'Microsoft'), please download our new language server Pylance from the VS Code marketplace to see if that fixes your issue]

Expected behaviour

Virtual environments just created will end up in list of kernels.

Actual behaviour

Virtual environments do not appear as kernels

Steps to reproduce:

[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

1. Create virtual env outside of vs code
2. Open VS code in same root folder
3. Open notebook
4. New venv is not selectable as a kernel.
5. Open python file
6. New venv is selectable as a python interpreter.

This test run is failing for the same reason:
https://github.com/microsoft/vscode-jupyter/runs/3669744903?check_suite_focus=true

Logs

Here's the logs from jupyter. Notice how the venv 'testDummyVenv' is not listed.
jupyterlog.txt

Here's the logs from python. venv 'testDummyVenv' is listed.
pythonlog.txt

We (Jupyter) are not getting the new venv when calling getInterpreterList. This seems like a recent regression.

[rchiodo]

Related: microsoft/vscode-jupyter#5319

[rchiodo]

I'm going to look at this. It's blocking development in the jupyter extension.

[karrtikr]

@rchiodo If resource is passed as undefined, workspace envs are not reported as the VSCode API needs a URI: vscode.workspace.getWorkspaceFolder(uri), I think that's what is happening.

In the extension we get the resource using

vscode-python/src/client/interpreter/configuration/interpreterSelector/commands/base.ts

Lines 33 to 81 in c383e81

	protected async getConfigTarget(): Promise<
	| {
	folderUri: Resource;
	configTarget: ConfigurationTarget;
	}
	| undefined
	> {
	if (
	!Array.isArray(this.workspaceService.workspaceFolders) ||
	this.workspaceService.workspaceFolders.length === 0
	) {
	return {
	folderUri: undefined,
	configTarget: ConfigurationTarget.Global,
	};
	}
	if (!this.workspaceService.workspaceFile && this.workspaceService.workspaceFolders.length === 1) {
	return {
	folderUri: this.workspaceService.workspaceFolders[0].uri,
	configTarget: ConfigurationTarget.WorkspaceFolder,
	};
	}
	// Ok we have multiple workspaces, get the user to pick a folder.
	type WorkspaceSelectionQuickPickItem = QuickPickItem & { uri: Uri };
	const quickPickItems: WorkspaceSelectionQuickPickItem[] = [
	...this.workspaceService.workspaceFolders.map((w) => ({
	label: w.name,
	description: path.dirname(w.uri.fsPath),
	uri: w.uri,
	})),
	{
	label: Interpreters.entireWorkspace(),
	uri: this.workspaceService.workspaceFolders[0].uri,
	},
	];
	const selection = await this.applicationShell.showQuickPick(quickPickItems, {
	placeHolder: 'Select the workspace to set the interpreter',
	});
	return selection
	? selection.label === Interpreters.entireWorkspace()
	? { folderUri: selection.uri, configTarget: ConfigurationTarget.Workspace }
	: { folderUri: selection.uri, configTarget: ConfigurationTarget.WorkspaceFolder }
	: undefined;
	}
	}

[karrtikr]

We should probably use this logic if no resource is set instead of calling vscode api to get workspace folder directly

[rchiodo]

Not sure this fixed it. I can still repro it after rebuilding the bits locally.

[rchiodo]

Looks like the first call to getInterpreters can be out of date.

[karrtikr]

Looks like the first call to getInterpreters can be out of date.

Wasn't that always the case though? When a new workspace is opened, first call to getInterpreters always relied on the existing cache first, which won't have the latest environments unless discovery is finished.

I can reproduce this issue with the stable version of the extension as well, although when trying with the stable version, the kernel list eventually gets updated to contain the new environments, which doesn't make sense as Jupyter supposedly caches the getInterpreters() API call results 👀

[rchiodo]

Maybe the timing is different then. With stable our tests pass. With insiders our tests fail. Let me try on my machine

[rchiodo]

Using this version it doesn't repro for me.

Version: 2021.8.1159798656

Using this version it also doesn't repro for me:

Version: 2021.9.1246542782

[rchiodo]

But with insiders it does.

[rchiodo]

What version of the jupyter extension do you have? The jupyter cache is a recent thing that Don added.

[rchiodo]

Actually does it really matter? It's broken either way. Until the event is in the API it makes sense for it to force a refresh.

[karrtikr]

I am able to reproduce it with stable as well. The first query doesn't contain the envs if we click fast enough.

If we click the second time, it's in the list.

I was using v2021.8.2041215044 Jupyter always.

[karrtikr]

Actually does it really matter? It's broken either way. Until the event is in the API it makes sense for it to force a refresh.

Yeah, it just seems like it was never supposed to work.

[rchiodo]

Tests seem to be reproing this. I believe there's still a problem with untitled files. At least during our tests running.