Provide "Select Interpreter" for R (similar to Python)

[juliasilge]

The Python extension has a nice "Select Interpreter" UI experience with a quick pick, and in some situations, it is more useful and nicer than Positron's interpreter dropdown:

It is easier to see the paths, you can search, you can refresh, etc.

Let's create the equivalent experience for R interpreters as a first step. In the longer term, we may want to reconsider what each of these affordances are best suited for.

[ntluong95]

Is this also including virtual environment created by renv?

[jennybc]

In my head, the renv matter is filed in a slightly different folder. I think we should be able to discover the use of renv and act more appropriately. So that feels related, but no, not exactly what this issue is about. (I don't see an issue that really captures the renv case crisply, so perhaps I should do something about that.)

[jennybc]

In today's R meeting, I got folks to discuss the "why" of bringing the Python "Select interpreter" experience over to R. Because the facts on the ground tend to be very different, i.e. we aren't crawling the file system looking for R installations or environments.

Some of what such an interface can deliver:

• Search, e.g. on part of the path
• Refresh = cause discovery to happen again
• See the whole path. The current interpreter dropdown can make it hard to tell which one you want. User often can't see a disambiguating part.
• Organization into sections that reveals what sort of installation it is, how it was discovered, etc. This could have an interesting connection to Better UX for unsupported R versions #1397, i.e. discovered-but-unsupported versions could be presented in their own section

[juliasilge]

Turns out that we mostly already have this:

We do this by bouncing the command back to Positron itself:

positron/extensions/positron-r/src/commands.ts

Lines 159 to 161 in f4b7966

	vscode.commands.registerCommand('r.selectInterpreter', async () => {
	await vscode.commands.executeCommand('workbench.action.languageRuntime.select', 'r');
	}),

Search works ✅ and you can see the whole path ✅

Still TODO:

• Add an icon to refresh discovery to the existing quickpick
• Can we provide any helpful organization with the info that Positron has in the metadata?
• Do we need to add "Enter interpreter path" here? I tend to think not, for R users at least, and we can punt that to later
• The R command is called r.selectInterpreter while the Python command is python.setInterpreter. Do we need to make these the same, for the multi-session work?

[juliasilge]

There are downsides to having this in Positron itself, as a language runtime action:

• We don't currently have a way to kick off discovery for one language from the languageRuntimeService. In Add option to control startup behavior per language #6145 we are adding a way to exclude a language from discovery but would need to do extra work if we wanted to refresh the runtime list for one language. If this functionality lived in the extension like the Python one, we could refresh just the R interpreters.
• We can only use the Positron-level runtime metadata to organize the quickpick, which isn't as useful as metadata that the R extension holds about R installations. Similarly we cannot show folks discovered but not available R versions, because those don't get sent over to Positron at all.

I am leaning toward implementing a more R-specific version of the quickpick in the R extension itself. If I do that, is there benefit to keeping the generic runtime command around, for possible future other language packs? If refreshing is an important part of this UI (and remember we have no other way to let users refresh discovery), then we'll probably always want this kind of functionality in language packs.

[jmcphers]

I think it makes the most sense for individual languages to implement interpreter selectors since (as you noted) there are often nuances or details specific to a language that make it difficult to build a generic UI that will serve everyone.

It would be helpful for there to be some sort of workflow for re-initiating discovery for a language that was driven from the Positron side, but I don't think that needs to happen here. R discovery is so fast that we could probably even do it to build the quickpick, and if the user chooses a version of R that wasn't in the set we initially delivered to Positron, we can do a just-in-time registration.

The generic interpreter selection command isn't that useful for end users, but I think it's helpful to us as a debugging tool and as a stable way of picking interpreters in test automation.

[juliasilge]

The QuickPickItem doesn't currently let us show an item but make it non-clickable, i.e. grayed out or similar. That means we can't currently do work to surface the discovered but not-usable R installations; that would need to involve changes to the quickpick infrastructure.

So overall what that means is that the only thing we're really gaining at the current moment is to initiate discovery. Probably still worth doing (given that I almost have it finished), but not a huge win over the existing language agnostic workbench.action.languageRuntime.select.