Add option to control startup behavior per language #6145
Conversation
…ior-configuration
…ior-configuration
…ior-configuration
…ior-configuration
|
E2E Tests 🚀 |
jmcphers
changed the title
There was a problem hiding this comment.
I was able to set up my workspace as R-only and not see any other language runtimes 🎉
Showing the settings.json directly, as I can't seem to show the Python and Zed settings overrides at the same time in the Settings UI.
Clearing the affiliated interpreter worked well when I had startupBehavior "manual" 👍
| // Remove the mainThreadLanguageRuntime instance id to the set of mainThreadLanguageRuntimes. | ||
| this._discoveryCompleteByExtHostId.delete(id); | ||
| this._logService.debug(`[Runtime startup] Unregistered extension host with id: ${id}.`); | ||
| // this._discoveryCompleteByExtHostId.set(id, false); |
There was a problem hiding this comment.
maybe leftover or unintentionally commented out?
There was a problem hiding this comment.
Yes, I think this just needs to pass the right ID value. Thanks!
src/vs/workbench/services/runtimeStartup/common/runtimeStartup.ts
Outdated
Show resolved
Hide resolved
src/vs/workbench/services/runtimeStartup/common/runtimeStartup.ts
Outdated
Show resolved
Hide resolved
src/vs/workbench/services/runtimeStartup/common/runtimeStartup.ts
Outdated
Show resolved
Hide resolved
src/vs/workbench/services/languageRuntime/common/languageRuntime.ts
Outdated
Show resolved
Hide resolved
| enumDescriptions: [ | ||
| nls.localize( | ||
| 'positron.runtime.startupBehavior.always', | ||
| "An interpreter will start in each new Positron window."), |
There was a problem hiding this comment.
Can we say a bit more about which interpreter might start, to differentiate from auto and recommended? Perhaps we can say something like "the interpreter Positron has affiliated with the workspace", or something like "Positron will infer which interpreter to start based on previous usage and extension metadata." (although this is starting to sound like auto...)
There was a problem hiding this comment.
Thanks, I took a crack at improving this in 8f0473c. This option is hard to describe succinctly and it really only makes sense when used for a specific language. I think only admins are likely to set it, though I could be wrong!
| * right away, or any other value to save the runtime as the project | ||
| * default without starting it. | ||
| */ | ||
| recommendedWorkspaceRuntime(): Thenable<LanguageRuntimeMetadata | undefined>; |
There was a problem hiding this comment.
Checking my understanding! Does this sound right?
Extensions will determine this recommended runtime, likely with this order of precedence:
- Has the user indicated a default runtime at the Workspace level? i.e.
python.defaultInterpreterPath, an upcomingr.interpreters.defaultoption; startupBehaviorImmediately - Is anything else in this workspace indicating a preferred runtime? i.e. Venv, DESCRIPTION, etc.; startupBehavior
Immediately - Consult User-level setting for default runtime? i.e.
python.defaultInterpreterPath, an upcomingr.interpreters.defaultoption; startupBehaviorImplicit
There was a problem hiding this comment.
Just about! For (1) I don't think we want Immediately because having the admin specific default paths doesn't necessarily mean that we want to always start that interpreter (i.e. "use this python by default" != "always start python in every project").
There was a problem hiding this comment.
Ah, gotcha -- thank you! Updating my notes accordingly 👌
src/vs/workbench/contrib/languageRuntime/browser/languageRuntimeActions.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: sharon <[email protected]> Signed-off-by: Jonathan <[email protected]>
Co-authored-by: sharon <[email protected]> Signed-off-by: Jonathan <[email protected]>
|
Both are probably helpful! I think admin docs are the most important since the primary motivation is Workbench. |
This change adds a new option that can be used to gain more control of how Positron starts an interpreter for each language.
The default value, auto, gives the automatic behavior we have today; the others (enumerated in documentation elsewhere) are new behaviors.
In addition, this PR adds a new feature that allows a language pack to tell Positron which runtime to start for a workspace before discovering all the runtimes on the machine. This happens during the Starting phase of the startup lifecycle.
Addresses #3575.
Release Notes
New Features
Bug Fixes
QA Notes
This new option replaces the old
interpreters.automaticStartupoption (I think having both would be too confusing). If memory serves we're using that today in theqa-example-contentrepro. PR updating this option here: posit-dev/qa-example-content#44As a debugging aid, I've added a way to show and clear which runtimes are "affiliated" with the workspace. The new
Interpreter: Clear Saved Interpretercommand can be used to show you which R/Python/etc. versions Positron has saved as the ones for your workspace.We will ultimately need more and better UI for choosing what interpreter is associated with your project; this command should be seen as a stopgap/debugging aid.
I've also added a couple of options to the Zed test language runtime so that in a dev build you can try out the 'recommended for workspace' workflow.