bug: fix path resolution to use resolved environment directly from settings#1229
bug: fix path resolution to use resolved environment directly from settings#1229eleanorjboyd wants to merge 1 commit intomicrosoft:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adjusts interpreter selection when resolving python.defaultInterpreterPath, switching from constructing a wrapper PythonEnvironment to reusing the PythonEnvironment returned by api.resolveEnvironment() so the selected environment uses the canonical environment identifier.
Changes:
- Removed the custom “defaultInterpreterPath:*” wrapper environment construction.
- Return the
resolvedEnvdirectly (and add verbose logging including the resolved environment ID).
| // Use the resolved environment directly - it has the canonical ID format | ||
| // The 'source' field tracks that this came from defaultInterpreterPath setting | ||
| traceVerbose( | ||
| `[tryResolveInterpreterPath] Resolved '${interpreterPath}' to ${resolved.executable} (${resolved.version})`, | ||
| `[tryResolveInterpreterPath] Resolved '${interpreterPath}' to ${resolved.executable} (${resolved.version}) with ID ${resolvedEnv.envId.id}`, | ||
| ); | ||
| return { manager, environment: newEnv, source: 'defaultInterpreterPath' }; | ||
| return { manager, environment: resolvedEnv, source: 'defaultInterpreterPath' }; |
There was a problem hiding this comment.
Returning resolvedEnv directly changes behavior when nativeFinder.resolve() canonicalizes/follows symlinks: the selected environment will now expose the resolved executable path (e.g., Homebrew) rather than the user-configured defaultInterpreterPath value. This currently contradicts the existing unit test should use original user path even when nativeFinder resolves to a different executable and will fail. Either update the tests/expected behavior, or keep the canonical envId from resolvedEnv but override the path fields (displayPath/environmentPath/execInfo.run.executable) to preserve the user-configured path.
See below for a potential fix:
// Use the resolved environment's canonical ID and metadata, but preserve the user-configured
// interpreterPath for all user-facing path fields. This matches the expectation that
// defaultInterpreterPath remains visible even if nativeFinder.resolve() canonicalizes/follows symlinks.
const selectedEnv: PythonEnvironment = {
...resolvedEnv,
displayPath: interpreterPath,
environmentPath: interpreterPath,
execInfo:
resolvedEnv.execInfo && resolvedEnv.execInfo.run
? {
...resolvedEnv.execInfo,
run: {
...resolvedEnv.execInfo.run,
executable: interpreterPath,
},
}
: resolvedEnv.execInfo,
};
traceVerbose(
`[tryResolveInterpreterPath] Resolved '${interpreterPath}' to ${resolved.executable} (${resolved.version}) with ID ${resolvedEnv.envId.id}`,
);
return { manager, environment: selectedEnv, source: 'defaultInterpreterPath' };
No description provided.