Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Syncs upstream template changes to prefer the Python Environments extension (ms-python.vscode-python-envs) for interpreter resolution, with a fallback to the legacy Python extension (ms-python.python).
Changes:
- Added typings for the
ms-python.vscode-python-envsextension API. - Updated interpreter initialization and resolution to prefer the envs extension, with legacy fallback.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
src/typings/pythonEnvironments.d.ts |
Adds TypeScript typings for the Python Environments extension API used by the client code. |
src/common/python.ts |
Adds envs-extension discovery/activation and uses it for interpreter resolution + change notifications, with legacy fallback. |
Contributor
Author
Manual Testing PlanSetup: Open this repo in VS Code, press All breakpoints are in Phase 1: Legacy Path (No Envs Extension)
Phase 2: Envs Extension Path
Phase 3: Interpreter Switching
Phase 4: Conda / Wrapper Environments
Phase 5: Build Verification
Priority: Tests 1.1, 2.1, 2.3, and 5.1 are the most critical. Quick sanity check: Set breakpoints on just lines 66, 178, 186, 204, and 209 — those 5 lines tell you which path was taken and what was returned. |
…esolution Syncs changes from microsoft/vscode-python-tools-extension-template#263. - Add src/typings/pythonEnvironments.d.ts with PythonEnvironmentsAPI type definitions - Update src/common/python.ts to prefer the ms-python.vscode-python-envs extension when available, falling back to the legacy ms-python.python extension The legacy ms-python.python extension API returns incorrect interpreter paths for uv-managed (and other modern) virtual environments. The new Python Environments extension provides a more comprehensive view of available environments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- Use import type for PythonEnvironmentsAPI - Standardize getEnvironmentsExtensionAPI with try/catch and null-exports check - Add version validation for envs API path - Add defensive null checks on execInfo.run.executable - Align comments and log messages across repos - Add TODO comments for unused and unimplemented code Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… helper - Add parsePythonVersion() for robust version string parsing with NaN validation - Add convertToResolvedEnvironment() to convert PythonEnvironment to ResolvedEnvironment - resolveInterpreter now calls envsApi.resolveEnvironment() with type conversion - getInterpreterDetails uses parsePythonVersion instead of inline split/map Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Prefer activatedRun over run in getInterpreterDetails and convertToResolvedEnvironment - Include args array in interpreter path for conda/pyenv shim support - Fall through to legacy ms-python.python when envs API returns no environment - Wrap envs API getEnvironment call in try/catch for resilience Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Versions like '3.13.0rc1' caused Number('0rc1') to return NaN,
rejecting valid interpreters. parseInt extracts the leading numeric
prefix correctly (e.g. parseInt('0rc1', 10) = 0).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace hand-rolled parseInt parsing with semver.coerce() which robustly handles pre-release versions (e.g. 3.13.0rc1, 3.12.0a4) and edge cases. Added semver as direct dependency and @types/semver as devDependency. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Closed
b21e663 to
c258896
Compare
bschnurr
approved these changes
Mar 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔄 Template Sync
This PR syncs changes from the upstream vscode-python-tools-extension-template.
Source PR(s)
Changes Applied
src/typings/pythonEnvironments.d.ts(new file): Added type definitions for thems-python.vscode-python-envsextension API (PythonEnvironmentsAPI,PythonEnvironment,DidChangeEnvironmentEventArgs, etc.).src/common/python.ts: UpdatedinitializePython()andgetInterpreterDetails()to prefer the Python Environments extension when available, with a graceful fallback to the legacyms-python.pythonextension. AddedgetEnvironmentsExtensionAPI()helper. The black-formatter-specific helpers (sameInterpreter,checkAndFireEvent,refreshServerPython,checkVersion) are preserved.checkVersion()(unlike the legacy fallback), consistent with the template. If version validation is needed for the new API, it would need to be added separately by parsing theversionstring field.🤖 This PR was auto-generated by the
extension-template-syncworkflow.