Interpreter picker waits for unrelated environment discovery

[eleanorjboyd]

Problem

The Python Environments interpreter picker does not appear until every environment manager finishes listing its environments. A slow interpreter associated with project A can therefore prevent opening project B's picker, even when B's saved interpreter is already available and running correctly.

The delay also withholds Browse... and the known recommended interpreter. This is a picker-responsiveness issue, not a finding that project B cannot execute Python.

Controlled reproduction

Use disposable environments only. This reproduction deliberately delays an interpreter subprocess; it does not require or establish a naturally slow machine.

1. Create a multi-root workspace with projects A and B, and separate virtual environments selected-a and selected-b outside those project folders.
2. Select the corresponding environment for each project, verify the selections, and close VS Code so they are persisted.
3. In the disposable selected-a environment, copy the real Python executable to bin/python-real. Replace only its bin/python symlink with an executable wrapper that waits for a local release marker before delegating to python-real (example below).
4. Reopen the same workspace/profile. Wait until discovery enters A's wrapper. Open a Python file in B and run it: B's saved interpreter should still execute successfully and its status bar should show the correct environment.
5. Invoke the Python Environments environment-selection command for B. In the development-host reproduction, this was vscode.commands.executeCommand('python-envs.set', projectBUri), which targets B directly rather than opening a preliminary workspace chooser. Observe that the environment picker is absent while A remains blocked.
6. Create A's release marker. Observe that the requested Select a Python Environment picker now appears, including Browse..., the recommended B environment, and discovered environments.
7. Repeat with B first in workspace order, then with the release marker present before startup. Reordering does not remove the picker delay; the no-delay control opens the picker normally.

Disposable macOS fixture wrapper

After copying the interpreter to bin/python-real, unlink only the test environment's bin/python symlink and create an executable file in its place containing:

#!/bin/sh
bin_dir=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd) || exit 1
touch "$bin_dir/selection-audit-started"
attempt=0
while [ ! -f "$bin_dir/selection-audit-release" ]; do
    attempt=$((attempt + 1))
    if [ "$attempt" -ge 200 ]; then
        echo "Test interpreter gate timed out" >&2
        exit 77
    fi
    sleep 0.1
done
exec "$bin_dir/python-real" "$@"

The marker belongs in the same bin directory. Remove the marker before each delayed run. Do not modify a system interpreter or an environment used for real work.

Expected behavior

Display the picker with already-known choices and an appropriate loading indication without waiting for unrelated discovery. Keep it dismissible, and incorporate additional results without reopening a dismissed picker or disrupting the user's selection.

Source-level cause

• pickEnvironment awaits each manager's getEnvironments('all') before calling pickEnvironmentImpl, which displays the UI. Browse and recommended items have already been constructed but are not yet shown.
• VenvManager.getEnvironments waits for full initialization. Its per-project get fast path can return B's saved environment while initialization remains pending.

A separate controlled probe of the production picker confirmed that a pending unrelated manager prevents UI presentation even when a healthy manager has already returned and a recommended environment is supplied.

Simply parallelizing initial workspace selection, or awaiting all managers concurrently before showing the picker, would retain the all-results-before-UI dependency.

Steps to verify a fix

1. Hold one manager's discovery pending while another manager and the recommended environment are available.
2. Open the picker and verify that it appears with known choices and Browse... before the pending manager finishes.
3. Release discovery and verify that additional results become available without losing the user's current focus.
4. Dismiss the picker while discovery is pending, then release it and verify that the picker does not reopen.
5. Exercise cancellation/back navigation where offered and verify that late results do not alter another picker.
6. Make one manager fail and verify that healthy choices remain usable with explicit error handling.
7. Repeat without delayed discovery and verify ordinary selection behavior.

Validation scope

Tested on macOS arm64 with an unmodified development build from commit 4ab81cfabe1652f43f689eefcbd67eaa0f23ffef, the Python extension present, real persisted virtual-environment selections, real discovery subprocesses, and actual Run File output. Picker visibility was checked in the real VS Code renderer before and after releasing the delayed interpreter.

The scoped picker reproduced the delay with both folder orders; the healthy control displayed it normally. B's API lookup, status bar, and execution remained functional during the wait.

The delay is controlled fault injection, not evidence of its frequency in the field. Native Windows/Linux, a released VSIX, and the full legacy Python: Select Interpreter workspace-chooser-to-environment-list interaction were not tested.

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: Please try again later, or contact support if the problem persists. (Request id: CF8E:B645C:1D1AA:28F67:6AC6CB65)