Add support for running code in separate process but same runtime

[juliasilge]

Right now, the executeCode API runs code in the console as if the user has typed the code. This is a great fit for many tasks, but there are situations where you want to run code in a separate process, especially a totally clean/fresh one:

• Running R package tests
• Checking an R package

We can't use the the default terminal execution for this, because what you get calling R or Python from the terminal is not guaranteed to be the right runtime.

What we are looking for is similar to how the RStudio Build Pane or Background Jobs behaves, although I don't know if we will want a similar UI. Even if we don't want UI like that, we will eventually need to get to a separate process of the right runtime.

[seeM]

We can't use the the default terminal execution for this, because what you get calling R or Python from the terminal is not guaranteed to be the right runtime.

Could we use default terminal execution but with the full runtime path? E.g. in Python, something like ~/.pyenv/versions/3.12.0a7/bin/python some-command instead of python some-command. I'm not sure if that would work in R.

[juliasilge]

Ah yes, that may be the way to go, especially initially. In R, we have full runtime path in the metadata that looks like '/Library/Frameworks/R.framework/Resources' so we could do /Library/Frameworks/R.framework/Resources/R -e 'some-R-code'.

If we did this, I think we would want to use the Task API because it has pretty nice infrastructure for this, ability to parse problems in output, etc.

[hadley]

FWIW I think the importance of the build pane is not just a separate process, but also a separate place to put output that's not the console.

[jennybc]

I am definitely running into problems from running devtools::check() in the main R session. It clearly changes some options or env vars (which is also a problem, but presumably my problem 😬 ), which, for vroom, creates spurious test failures in subsequent calls to devtools::test().

Now, obviously, devtools::check() (or maybe vroom's tests?) are part of the problem here. But this underscores that it would be really great to get these package dev tasks out of the user's R session.

[lionel-]

The check task running in the terminal looks nice! I agree that it would be better in the side bar. Should we move the terminal there by default? It would look like:

Screen.Recording.2023-10-04.at.15.52.45.mov

Nit: I was a bit surprised to see mentions of the quarto and git extensions in the tooltip:

Not a big deal and I guess this might be sorted out once we have a dedicated build pane though.

@juliasilge Should the "Test" command also be run as a terminal task before we close this issue? It's currently still running in the console. What about "Install package"?

[juliasilge]

Yep, the changes for testing are being tracked in #1365 and for install/restart/library() in #1279. This issue is about adding the ability to run code in a separate process but the same runtime as a task.

[lionel-]

Sounds good, so we can close this issue! The terminal tasks are looking great.

I posted my notes about moving the terminal to the side bar in #1486