User friendly error message when vsc.rstudioapi is not set

[matthiasgomolka]

Describe the bug When I want to use an RStudio Addin from VS Code I receive the following error:

Command 'R: Launch RStudio Addin' resulted in an error (ENOENT: no such file or directory, open '/tmp/RtmpKarM0O/vscode-R/addins.json')

I set options(vsc.rstudioapi = TRUE) in my radian profile. This works (checked using getOption("vsc.rstudioapi")).

To Reproduce Steps to reproduce the behavior:

1. Open VS Code
2. Press 'F1' to open the command palette
3. Choose 'R: Launch RStudio Addin'
4. See error

Do you want to fix by self? (I hope your help!)

No (don't know how)

Expected behavior I should be able to choose from installed RStudio Addins.

Screenshots

Environment (please complete the following information):

• OS: Linux
• VSCode Version: 1.51.0
• R Version: 4.0.3
• vscode-R version: 1.5.2

[renkun-ken]

Before the R session sources session watcher init.R script, options(vsc.rstudioapi = TRUE) has to be set to enable addins emulation layer which provides the list of addins available in the R session via {session-tempdir}/vscode-R/addins.json.

This issue is more like we could show a more user-friendly error message to tell user that options(vsc.rstudioapi = TRUE) has to be set in user profile to enable this feature.

[matthiasgomolka]

Thanks. But which user profile? I think I already tried all (or most) of the possibilities and the radian profile was the one where the option was set right away when the session started.

[renkun-ken]

The user profile (~/.Rprofile) and project profile {profileFolder}/.Rprofile both should work. The radian profile is used when you start radian which does not work with the original R terminal. If you intend to make it only work with radian, then I guess using radian profile is fine.

You could always run the following in R to edit your user profile:

file.edit("~/.Rprofile")

[matthiasgomolka]

It's somehow related to radian. When I switch to the standard R console, it works as expected. Any ideas what might have gone wrong with radian?

[matthiasgomolka]

Thanks for your patience! Figured it out:

I needed to set the following in VS code:

Or as JSON:

"r.alwaysUseActiveTerminal": true

Not sure if this was initially activated, but might be useful to document here: https://github.com/Ikuyadeu/vscode-R/wiki/RStudio-addin-support.

[MilesMcBain]

I'm looking at making a nicer error in this case. Sorry for the confusion @matthiasgomolka!

[MilesMcBain]

So I use Radian, and do not have the 'always use' checkbox ticked. In testing, I set vsc.rstudioapi in my .Rprofile and things worked as expected.

What do we know about how or when the .radian_profile is used? It seems like it is not interchangeable with R profile?

[renkun-ken]

r.alwaysUseActiveTerminal is mainly used to support sending code to R terminals started by user as introduced at the wiki. It should not have anything to do with rstudioapi stuff.

If one always starts own R terminals (I always starts radian in a tmux window), then one has to add the source init.R code to the user profile (~/.Rprofile) so that session watcher and rstudioapi emulation could load and attach on each R session startup.

.radian_profile is only sourced by radian on session startup. If the same code appears in ~/.Rprofile, then it should work for all R sessions started with this user profile including radian sessions, and the same code is not needed in .radian_profile. If you only want some code to run on radian startup (instead of R), then you should write it in .radian_profile.

[MilesMcBain]

But from the sounds of things there might be an ordering issue? Like the .radian_profile is sourced after the .Rprofile and it is the .Rprofile that triggers init.R in the standard usecase.

[MilesMcBain]

Also thanks for the explanation that clarified the self-managed thing for me. :+1:

[renkun-ken]

But from the sounds of things there might be an ordering issue? Like the .radian_profile is sourced after the .Rprofile and it is the .Rprofile that triggers init.R in the standard usecase.

I think it is true. See https://github.com/randy3k/radian/blob/364b389170ed1e8744a8fada350a52b673a7e499/radian/radianapp.py#L97.

[renkun-ken]

Closing as resolved.

[yonicd]

would it be possible to expose the option to settings.json level, for packages that depend on it being preset to TRUE there is a timing problem since .Rprofile is already sourced by the time the package is loaded into the namespace.

wouldnt having it as an option in the json would supersede any rprofile timing issue?

An example of this would be {whereami}.

[MilesMcBain]

I don't think that's true unfortunately. Even if it's elevated to settings, it still needs to do work at the start of the R Session to shim the API. This is done in the initialisation routine, which is run after the profile is sourced since the profile can control many vsocde-R features.

It would be a bit of a rejig, involving a new way of passing context to the R session to get this to work.

Maybe describe the specific timing issue in a new issue? I made a PR just recently to fix one such issue: https://github.com/Ikuyadeu/vscode-R/pull/610

It seems like this should fix your problem since {whereami} doesn't try to do anything with the {rstudioapi} during its onLoad?

[yonicd]

{whereami} doesn't do anything .onLoad but it does depend heavily on rstudioapi. If there is a simple way to invoke the option for vsc.rstudioapi .onLoad then that would be best, otherwise it creates an unnatural usage for a package that goes beyond the namespace. The user would need to manually control Rprofile when loading the namespace.

Would it make sense to have an explicit function to enable vsc.rstudioapi from an already active session? This way the developer can use it in an .onLoad to activate the necessary utility functions when Sys.getenv("TERM_PROGRAM") == "vscode"

[MilesMcBain]

I think whether the API is used or not needs to remain under user control, because the emulation is far from perfect. The user needs to be able to run sessions without it to let certain tools use their fallback behavior for when they detect no API.

It doesn't make sense to me to have situations where packages can enable the API if the shims are not present in the namespace as you seem to be suggesting.

Definitely things are a bit weird. But we're pretending to be rstudio here and the API was clearly not designed to be a general addin API, so that kind of comes with that.

I still don't understand the problem you have. Please spell it out for me in a new issue and I might be able to help.