Python: Immediately start a Python runtime in Python workspaces

[seeM]

Via @petetronic:

If we find we are being opened in a Folder that is predominantly Python - perhaps we could start simple and just say we find .py files, or if there are better heuristics from the MS Python extension already - and just mark the preferred Python interpreter as Immediate

[petetronic]

Related to a request for R in #72

[petetronic]

Some activation events from the python extension include:

        "workspaceContains:mspythonconfig.json",
        "workspaceContains:pyproject.toml",
        "workspaceContains:Pipfile",
        "workspaceContains:setup.py",
        "workspaceContains:requirements.txt",
        "workspaceContains:manage.py",
        "workspaceContains:app.py"

[jmcphers]

We may be able to remove this hack once the Python extension accepts responsibility for starting Python when appropriate:

positron/src/vs/workbench/services/languageRuntime/common/languageRuntime.ts

Lines 459 to 482 in 707042f

	// --- Begin TEMPORARY ---
	// We want to start a Python runtime as a last-chance fallback if we have no other
	// runtimes to start. We consider this to be true under the following circumstances:
	//
	// - We have completed the discovery phase, which implies we've also started any
	// runtimes that asked to be started right away (startupBehavior === Immediate).
	// - No runtimes have been started or are running yet.
	// - This was not an initially untrusted workspace; in these workspaces, we don't
	// know what would have been automatically started, so we don't want to come
	// stomping in and starting a Python runtime.
	// - No runtimes will be automatically started for this workspace, i.e. this workspace
	// has no affiliated runtimes.
	//
	// This behavior shouldn't live here, but it does until the Python language pack
	// can be updated. See https://github.com/rstudio/positron/issues/1009
	if (this._discoveryPhase === LanguageRuntimeDiscoveryPhase.Complete &&
	!this.hasAnyStartedOrRunningRuntimes() &&
	languageRuntimeInfo.runtime.metadata.languageId === 'python' &&
	this._initiallyTrustedWorkspace === true &&
	!this._workspaceAffiliation.hasAffiliatedRuntime()) {
	this.autoStartRuntime(languageRuntimeInfo.runtime,
	`No other language runtimes want to start; Python is the default.`);
	}
	// --- End TEMPORARY ---

[seeM]

[...] once the Python extension accepts responsibility for starting Python when appropriate

@jmcphers I need to do some more testing to see whether activating eagerly actually brings Python into the discovery phase, I'd like to track that in #1009.

Until then, I think a good step for this issue for alpha would be:

1. Update R to only enable immediate startup if the workspace has R files, or if it's empty and the user has RStudio installed i.e. hasRFiles || (isEmpty && isRStudioUser).
2. Update Python to only enable immediate startup if the workspace contains Python files (including the non .py files Pete mentioned).

That way, R won't be started at all in folders that only contain Python files, and vice versa, until we figure out #1009. I've got branches of positron and positron-python running with this setup and I think it's a big improvement over the current behavior.

What do you think?

---

I also foresee a separate/related issue by looking at the code, but I haven't tested yet:

I'm not sure how Positron will currently react to multiple languages registering a runtime with immediate startup behavior (EDIT: all within the discovery phase). IIUC it would start whichever language happened to start register a runtime first. Is that a bug or intended?

positron/src/vs/workbench/services/languageRuntime/common/languageRuntime.ts

Lines 503 to 509 in a4ad542

	const languageRuntimeInfos = this._registeredRuntimes.filter(
	info => info.startupBehavior === LanguageRuntimeStartupBehavior.Immediate);
	if (languageRuntimeInfos.length) {
	this.autoStartRuntime(languageRuntimeInfos[0].runtime,
	`An extension requested the runtime to be started immediately.`);
	}
	}

[juliasilge]

I think hasRFiles() should return true with only R Markdown or Quarto files as well.

[seeM]

This is ready for review in 2023.09.0-139. It's worth testing in both R and Python projects. Note that this should only affect opening new workspaces

[juliasilge]

I just spent some time testing this out with build 139. I have used RStudio as my IDE for... everything 😆 for a while now so it was a pretty good way to explore it.

• My R package projects all still start R ✅
  • (Side note, this includes yardstick which actually runs Python code, but from a R file!)
• I have used RStudio as my IDE for Python projects (like Python packages) and these start Python even though they have .Rproj files and friends, since they also have Python files ✅
• My projects that are talks or websites (no .R or .py files) open R, since I used RStudio with them. In my case, none of these were Python projects, but I expect if they were, R would have started. Certainly I am unusual in using RStudio as my IDE for Python projects, though.

[seeM]

Thank you @juliasilge!

Re your 3rd point: Positron doesn't currently support starting more than one runtime with immediate startup behavior. Atm it will only start the first "immediate" runtime registered, which is most often R (since it registers much faster than Python). I think we'd need to file that as a separate feature request/bug if it's something we think is important. Perhaps we want to start at most one runtime per language instead of globally, as it currently is.

Given that, I'm surprised that Python started even though there was a .Rproj file! Since .Rproj could mean either R or Python, maybe we should remove it from the R startup heuristic?

[juliasilge]

If we don't add .Rproj as one of the triggers to start R, then it won't start in projects for RStudio users that are all .qmd files. (Some of those other files like .Rprofile are not as commonly used, and things like .Rbuildignore are only for R packages, which have .R files anyway.) My guess is that the situation of an RStudio user having no signals but .Rproj and wanting to use R much be way more common than people who use RStudio as their IDE for Python projects.

[seeM]

@juliasilge great, I agree. In that case, are you happy with us closing this as "done" or is there still anything outstanding?

[juliasilge]

Yes! From my perspective, looks great. 👍