Add TypeScript interpreter detection module#3703
Conversation
christierney
left a comment
christierney
left a comment
There was a problem hiding this comment.
It seems like the version constraint function only get applied to the version strings from certain files, not all (e.g. .python-version but not pyproject.toml). Is that intentional?
| } | ||
| if (!config.configuration.r.requiresR) { | ||
| config.configuration.r.requiresR = defaults.r.requiresR; | ||
| } |
There was a problem hiding this comment.
I wonder if this should have been included when I added these fields to the configuration types. This is technically a behavior change, right? Even though the rest of this PR is not wired up to anything yet?
There was a problem hiding this comment.
yeah, I suppose it is - this change is weird because of of how the config got filled in on the go side vs how we're doing it now on the typescript side.
There was a problem hiding this comment.
to keep this PR self-contained and scoped to just implementation + tests without behavior changes, I could pull this out.
There was a problem hiding this comment.
that actually is nice - because it also forces the types for interpreters to be self-contained in this module as well - before we were relying on the old api types, which feels weird.
There was a problem hiding this comment.
I'm not sure I follow 😄 but I'm good with whatever, just wanted to mention it
Add a self-contained TypeScript module for detecting Python and R interpreters, replacing the Go backend's /api/interpreters endpoint. The module includes: - Version constraint parsing (requires-python/requires-r from metadata) - Python interpreter detection via sys.executable and version probing - R interpreter detection via R --version parsing - Shared filesystem utilities for reading files and checking existence All source files use only Node.js builtins (no vscode dependency), making the module testable in isolation with vitest. The module defines its own local types (PythonInterpreterConfig, RInterpreterConfig, InterpreterDetectionResult) so no existing files are modified. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
zackverham
force-pushed
the
interpreters-module
branch
from
9103644 to
60901e6
Compare
I looked into this - it looks like .python-version in particular can just specify the version, not a PEP 440 version constraint, which is why there's extra handling there. https://packaging.python.org/en/latest/specifications/pyproject-toml/#requires-python |
3 participants
Summary
src/interpreters/) for detecting Python and R interpretersrequiresPython/requiresRfields toPythonConfig/RConfigtypes and fill-in logic inUpdateConfigWithDefaultsvscodedependency), making the module testable in isolationThis is PR 1 of 3 splitting up #3672. The module is entirely new code with no behavior change — it has no consumers yet.
PR chain: PR 1 (this) → PR 2 (wire into state.ts) → PR 3 (integration tests + CI)
Test plan
npx tsc --noEmitpassesnpx vitest run src/interpreters/— 81 tests passnpx prettier --checkpasses🤖 Generated with Claude Code