-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Fix #12462, #14674 for debugging #14676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The corresponding PR on debugpy side is coming soon. |
debugOptions?: DebugOptions[]; | ||
env?: Record<string, string | undefined>; | ||
envFile: string; | ||
envFile?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far as I can tell, these properties have always been improperly typed - test code used casts and any
in places to work around that.
Codecov Report
@@ Coverage Diff @@
## main #14676 +/- ##
==========================================
+ Coverage 59.77% 64.85% +5.08%
==========================================
Files 670 547 -123
Lines 37212 25792 -11420
Branches 5270 3679 -1591
==========================================
- Hits 22243 16728 -5515
+ Misses 13841 8373 -5468
+ Partials 1128 691 -437
Continue to review full report at Codecov.
|
|
||
return config as LaunchRequestArguments; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is, essentially, the sequence of calls that VSCode itself performs:
resolveDebugConfiguration()
- substitute
${variables}
resolveDebugConfigurationWithSubstitutedVariables()
eb85b48
to
bb1067d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for working on this. I left a few comments mostly to clarify my understanding but I'm fine with the PR as-is.
// The following are all internal properties that are not publicly documented or | ||
// exposed in launch.json schema for the extension. | ||
|
||
// Python interpreter used by the extension to spawn the debug adapter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I personally try to call it "Python executable" (or sometimes "Python runtime") instead of "Python interpreter". The former is more correct while still being clear.
Then again, a lot of folks call it "interpreter" too, so it isn't a big deal. I suppose at this point my brain has sufficiently associated "interpreter" with that exact portion of the runtime such that hearing the word applied to the executable is now a bit uncomfortable for me. 😄 (Plus "interpreter" will probably be a little more confusing once subinterpreters are a bigger part of the Python experience.)
Just to be clear, this is not a request that you change anything (though I'd personally like that). I'm just pointing out something to think about that most of the time isn't obvious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been struggling with a good term for that for a very long time - this is partly why the new setting was called "python" back when debugpy added it; that way I can just say, "it's whatever goes in place of python
in the command line you'd typically use to start".
The main reason why it's "interpreter" here is because we have command:interpreterPath
. Also, generally speaking, more recent code in the extension seems to be using "interpreter" more often. It would be good to standardize on something across the codebase, whatever that ends up being.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, we made a decision a while back to not use the term "interpreter" so much, favoring "executable" or "environment" instead (depending on the context). Apparently we haven't been doing very well at that. 😞
src/client/debugger/extension/configuration/resolvers/launch.ts
Outdated
Show resolved
Hide resolved
Fix microsoft#12462: Update launch.json schema to add "python" and remove "pythonPath" Split the "pythonPath" debug property into "python", "debugAdapterPython", and "debugLauncherPython". Do most debug config validation on fully expanded property values via resolveDebugConfigurationWithSubstitutedVariables(). Add fixups for legacy launch.json with "pythonPath".
Kudos, SonarCloud Quality Gate passed!
|
…icrosoft#14676) Fix microsoft#12462: Update launch.json schema to add "python" and remove "pythonPath" Split the "pythonPath" debug property into "python", "debugAdapterPython", and "debugLauncherPython". Do most debug config validation on fully expanded property values via resolveDebugConfigurationWithSubstitutedVariables(). Add fixups for legacy launch.json with "pythonPath".
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #14676 +/- ##
=========================================
+ Coverage 59% 64% +5%
=========================================
Files 670 547 -123
Lines 37212 25792 -11420
Branches 5270 3679 -1591
=========================================
- Hits 22243 16728 -5515
+ Misses 13841 8373 -5468
+ Partials 1128 691 -437
🚀 New features to boost your workflow:
|
Fix #14674: Enable overriding "pythonPath" in the launcher
Fix #12462: Update launch.json schema to add "python" and remove "pythonPath"
Split the "pythonPath" debug property into "python", "debugAdapterPython", and "debugLauncherPython".
Properly register the python.interpreterPath command to expand the ${command:interpreterPath} debug configuration variable.
Do most debug config validation on fully expanded property values via resolveDebugConfigurationWithSubstitutedVariables().
Add fixups for legacy launch.json with "pythonPath" and/or "${command:python.interpreterPath}".
package-lock.json
has been regenerated by runningnpm install
(if dependencies have changed).