Fix global interpreter selection readback routing (#1922)

[Aadi Jain (Thrizzio)]

Summary

Fixes #1922

Fixes inconsistent global Python interpreter selection readback when the selected interpreter belongs to a different environment manager than the configured default.

In an empty VS Code window, selecting a non-venv interpreter (e.g. system or Conda) while ms-python.python:venv is the configured default could cause subsequent calls to getEnvironmentManager(undefined) and getEnvironment(undefined) to resolve through the venv manager instead of the manager associated with the selected environment.

Root Cause

Global interpreter selections are cached in _activeSelection under the global selection key. However, getConfiguredOrCachedEnvironmentManager() previously preferred the configured default manager over the manager associated with the cached global selection.

As a result, the configured default manager took precedence during subsequent global environment readback, even when the active selection belonged to another manager.

Changes

• src/features/envManagers.ts:
  • Prefer the cached global selection's manager when resolving for an empty-window global context (context === undefined), provided that manager is registered.
  • Preserve the existing configured/default manager fallback when no usable cached manager is available.
  • Preserve configured-manager precedence for workspace and folder contexts.
  • Maintain pure read semantics on getEnvironment(undefined) without writing manager defaults into User Settings.
• src/test/features/envManagers.unit.test.ts:
  • Add a regression test covering global selection of a system interpreter when the configured default manager is ms-python.python:venv.
  • Assert that manager resolution and getEnvironment(undefined) use the selected system interpreter's manager rather than the configured venv manager.

Related Issues (Context Only)

• Related to Non-venv python.defaultInterpreterPath is logged as selected but the newest Python is used #1885 and Refactor environment change events to make getEnvironment a pure read and add refreshEnvironment event #1495 (manager routing vs. active selection).
• Does not modify terminal shell-startup activation (New terminals retain old interpreter after global selection changes #1864) or loose-file state handling ([Python Environments] Activation of any other environments fail when opening file without workspace #1522, Route non-workspace files to an authoritative default environment context #1840).

Verification

• Automated Regression Test:
  • Confirmed to fail on base commit:

    AssertionError [ERR_ASSERTION]: A global selection must route through the selected environment manager
    + actual:   'ms-python.python:venv'
    - expected: 'ms-python.python:system'
    

  • Confirmed to pass after fix (2842 passing, 12 pending, 0 failing).
• Commands Run:
  • npm run compile-tests && npm run unittest (Pass)
  • npm run compile (Pass)
  • npm run lint (Pass)
  • git diff --check (Pass)
• Manual Verification:
  • Tested global interpreter selection in an empty VS Code window via Extension Development Host.
  • Selected a non-venv interpreter and verified that the Python Projects > Global sidebar view and subsequent readbacks immediately synchronize with the chosen environment.

[Aadi Jain (Thrizzio)]

@microsoft-github-policy-service agree

[Aadi Jain (Thrizzio)]

Hi Bill Schnurr (@bschnurr), Eduardo Villalpando Mello (@edvilme), and Rich Chiodo (@rchiodo),

I've opened this PR to address #1922.

The fix addresses global interpreter selection readback when the selected environment belongs to a different manager than the configured default. I've added regression coverage and run the unit tests, compilation, lint, and diff checks. I've also manually tested the selection flow in an empty VS Code window.

If screenshots or a short recording of the manual verification would be helpful, I'm happy to add them.

Thank you for your time!