Prefer using vscode-python-environments’ interpreter change event

[flying-sheep]

See “Layer 3” comment here: microsoft/vscode-python-environments#1491 (comment)

When you pick an env via [vscode-python-environments (VPE)]’ tree, we fire pythonEnvsApi.onDidChangeEnvironment (per-workspace). Both ruff-vscode and ty-vscode subscribe only to the legacy api.environments.onDidChangeActiveEnvironmentPath (global only), so they miss our selections — which is exactly why your Select Interpreter workaround "fixes" it (it sets the global env and fires the legacy event). Pylance already supports both APIs: it dual-subscribes, prefers ours when our extension is installed, falls back to the legacy event otherwise. We think that's the right model for ruff/ty too.

IDK how they do it (probably buried in some proprietary pylance code) but I can think of one optimal way:

1. check if the ms-python.vscode-python-envs extension API can be accessed, if not, load the ms-python.python extension
2. subscribe to the loaded extensions’ event
3. subscribe to the extension change event, and when either extension gets disabled, goto 1.

related: #479, astral-sh/ty-vscode#293

[MichaReiser]

We shoulld backport astral-sh/ty-vscode#293

[flying-sheep]

Could you do that please?

[MichaReiser]

I'm close. The only thing that's missing is testing the 30 or so combinations of configuration options 😅

[flying-sheep]

Ah sorry, I forgot this is in the works. With 4 open PRs I really should have checked. I didn’t want to rush you!