Should we offer a way to pin an R version for Positron, in a workspace?

[jennybc]

This notion is floating around in some issue comments and in live chats, so I want to record it for proper discussion.

Between the advent of rig (https://github.com/r-lib/rig) and Positron's interpreter drop-down, I feel like more R users are going to be living with multiple versions of R on their machine in the near future. The R world does not have the same culture of using environments as, say, Python and this is largely with good reason. Briefly, I think typical R user behaviour (using the same package library for most/all projects) is reasonable behaviour in lots of cases, due to CRAN's attention to reverse dependency breakage.

This brings up new questions about how to decide which version of R to fire up in a particular workspace.

Dumping some thoughts here:

• One option is to continue with what Positron does now: if the user has used R previously in the workspace, re-launch "whatever we did last time" (for some definition of what we did last time).
  • Taken very literally, this will eventually result in folks ending up in R 4.3.3 in some workspaces, but not others, even though they just updated to the shiny new R 4.4.0. That can only happen under certain scenarios. For example, the CRAN installer on macOS would have removed R 4.3.3, but rig will leave the previous installation intact. It depends on whether you've opened this workspace in Positron before. Etc, etc, etc. It's complicated.
  • A squishier interpretation of "what we did last time" is to notice if the last-used R version was also the current version (at that time) and, if so, launch whatever the current current [sic] R version is. This is Allow workspaces to open with "the current version of R" without any fuss #2535 and has been implemented as part of Handle unsupported R versions; prefer current "current" version of R #2652. Do we want to do this unconditionally (as Handle unsupported R versions; prefer current "current" version of R #2652 does)? Or only if the current current version is greater than the previous current? Or make it opt-in or opt-out?
• We could advise folks to use renv (https://rstudio.github.io/renv/) if a specific workspace needs to be managed with such care. But I do worry that that is a heavier lift than is necessary, if someone only wants to pin the R version and not necessarily the versions of every package the project uses.
• The positron-r extension could have a setting for the R version associated with the workspace. But this feels somewhat weird because, if the user bothers to configure this, surely they would want it to apply to other R sessions, even if not managed by Positron. You can easily imagine people continuing to use RStudio or another IDE or no IDE, while they also test drive Positron. But then again, those other ways of running R might not really support running something other than the current version of R.
• If folks are keeping multiple versions of R around, they better also be maintaining one package library for each minor version, presumably by exploiting the R_LIBS_USER env var as described, e.g. in rstats.wtf. I know rig tries to nudge people to keep minor-version-specific user libraries, but it's entirely possible that Positron should also help people fall into this Pit of Success.

[lionel-]

A good criterion for the selection procedure is one that is very easy to understand and predict. For the reasons you mentioned, the current approach of remembering implicitly the last launched version can be both surprising and hard to predict.

One way of making the selection more transparent would be to always use a generic selection procedure unless a different version has been explicitly pinned by the user. This could be via renv, but I'd also love a "pin to workspace" button in the runtime dropdown list. The visible pin would make it easy to understand that the default selection has been overridden. Maybe the workspace pin should be grayed out to indicate that the version is managed by renv, pyenv, or similar?

Regarding the default selection it could be one of these:

• Always the most recent version (with some heuristics to arbitrate duplicates but these should be rare). One big downside is that this would make it hard to work with a specific version of R for a little while. You'd have to use a pin for each project you're opening, and then undo the pin.

• Always the last selected version. This has the downside that installing a new version of R will not cause the new version to be launched, and might confuse users.

• The last selected version, unless a newer version of R has been installed, in that case it becomes implicitly the last selected version.

I think this last approach might work best overall.

[roaldarbol]

Just adding the idea from #3946 here with a few modifications:

In VS Code, it's possible to set the R installation to use for the workspace in .vscode/settings.json, e.g. this current setup that works nicely:

{
    "r.bracketedPaste": true,
    "r.plot.useHttpgd": true,
    "r.rpath.mac": "${workspaceFolder}/.pixi/envs/default/bin/R",
    "r.rterm.mac": "${workspaceFolder}/.pixi/envs/default/bin/radian",
    "r.rpath.linux": "${workspaceFolder}/.pixi/envs/default/bin/R",
    "r.rterm.linux": "${workspaceFolder}/.pixi/envs/default/bin/radian",
    "r.rpath.windows": "${workspaceFolder}/.pixi/envs/default/bin/R",
    "r.rterm.windows": "${workspaceFolder}/.pixi/envs/default/bin/radian"
}

Since Positron doesn't use the R extension, but your own - it currently doesn't work, but it would be a great way to handle it and it's already supported for VS Code, it would allow users who use this option to seamlessly transfer to Positron with only a few modifications. Alternatively, having a separate file that contains the R version, but that would mostly make sense if other IDEs (e.g. RStudio) could also read it. Then "Pin to workspace" could save to settings.json/alternative file.

This workflow means that whenever the workspace is opened, it automatically detects and chooses the R installation to use - e.g. in this template the user chooses their R version which is then installed from from conda-forge (r-base), so they'll always have just the right R version for the project, and so will everyone else who'd like to run the project.

Maybe a prioritised approach could look like this:

1. Explicit path set (in file, e.g. in settings.json)
2. If R installation present in workspace (e.g. pixi/venv), use that installation
3. If renv is used, use the appropriate system-wide installation (if present)
4. The last selected version, unless a newer version of R has been installed, in that case it becomes implicitly the last selected version (@lionel-'s last option)

[mollenburger]

In python you can already select an interpreter, eg from a conda env. It would be GREAT to be able to choose the R version in a given conda env as well

[jmcphers]

Related to #2235.