fix: use run.executable for interpreter identification instead of activatedRun.executable

[renan-r-santos]

Fixes microsoft/vscode-python-environments#987

Hi @eleanorjboyd. I saw you merged test discovery 2.0 and was very excited to test it. I still have environment activation issues after that PR was merged, so I decided to investigate it a bit further. I'd appreciate it if you could review this PR.

The debugger reads activatedRun.executable in three places to figure out which Python binary to use. This works today because every environment manager happens to set activatedRun.executable to the actual Python path, but it breaks when a manager sets it to a wrapper command (like pixi run ... python or how conda used to do conda run ... python before microsoft/vscode-python-environments#860).

I believe the three call sites (getInterpreterDetails, getSettingsPythonPath, getExecutableCommand) aren't running Python, they're identifying the interpreter for things like resolveEnvironment() and spawning the debug adapter. And I think that's what run.executable is for. activatedRun is for execution contexts like runInBackground in vscode-python-environments.

The change should be backwards compatible since run.executable and activatedRun.executable are currently the same value for all existing managers (venv, system, conda). It only matters when they differ, which is the case for pixi-code (see microsoft/vscode-python-environments#987 and #872).

Debuggee activation is not affected, that still goes through getActivatedEnvironmentVariables() and terminal envVarCollection.

This unblocks environment managers from setting activatedRun to a wrapper command like pixi run ... python, which is needed to fix pytest discovery not activating the environment (microsoft/vscode-python-environments#987). Right now runInBackground (used by test discovery) relies on activatedRun for execution, but managers can't set it to anything other than the bare Python path without breaking the debugger.

[Copilot]

Pull request overview

Updates interpreter identification in the debugger integration to consistently use execInfo.run.executable (the actual Python interpreter) rather than execInfo.activatedRun.executable (which may be a wrapper command), addressing activation/wrapper scenarios like pixi (vscode-python-environments#987 / vscode-python-debugger#872).

Changes:

• Use execInfo.run.executable when selecting the debug adapter’s Python executable.
• Use execInfo.run.executable when computing interpreter details and settings-based Python path for debug configuration resolution.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/extension/debugger/adapter/factory.ts	Ensures debug adapter launch uses run.executable only.
src/extension/common/python.ts	Ensures interpreter discovery/settings resolution uses run.executable only.

Comments suppressed due to low confidence (2)

src/extension/common/python.ts:142

• Behavior change: getSettingsPythonPath now always returns execInfo.run (ignoring activatedRun). Please add/update a unit test where execInfo.activatedRun points to a wrapper command and execInfo.run points to the actual Python executable to verify the returned command uses run.* as intended.

This issue also appears on line 255 of the same file.

        const runConfig = execInfo.run;
        traceLog(
            `getSettingsPythonPath: Using executable='${runConfig.executable}' args='${
                runConfig.args?.join(' ') || ''
            }'`,
        );
        return runConfig.args ? [runConfig.executable, ...runConfig.args] : [runConfig.executable];

src/extension/common/python.ts:265

• Behavior change: getInterpreterDetails now always reads resolvedEnv.execInfo.run.executable. Please add a unit test that simulates resolvedEnv.execInfo.activatedRun.executable being a wrapper command while run.executable is the true interpreter path, and assert that the returned IInterpreterDetails.path uses run.executable.

        const env: PythonEnvironment | undefined = await api.getEnvironment(resource);
        // resolve the environment to get full details
        const resolvedEnv = env ? await api.resolveEnvironment(env?.environmentPath) : undefined;
        const executablePath = resolvedEnv?.execInfo.run.executable;

        const a: IInterpreterDetails = {
            path: executablePath ? [executablePath] : undefined,
            resource,
        };
        traceLog(`getInterpreterDetails: resource='${resource?.fsPath}' executable='${executablePath}'`);
        return a;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Behavior change: this now always uses execInfo.run.executable and ignores activatedRun entirely. Please add/adjust a unit test covering an environment where activatedRun.executable is a wrapper command (e.g., 'pixi') while run.executable is the real Python binary, to ensure the debug adapter is launched with the real interpreter and to prevent regressions.

[eleanorjboyd]

We have some conflicting documentation on this so let me confirm desired behavior and then make updates. This makes sense to me and I really appreciate you investigating in such detail!!

[eleanorjboyd]

Yep confirmed you have the right ideas here using run not activatedRun. Thanks for catching this. Will get this merged then add a PR with testing