R Interactive does not respect R_LIBS_USER

[allefeld]

trafficstars

Describe the bug

I have a custom library set up for R, by setting R_LIBS_USER in my .bashrc. If I start R or radian in the terminal, that is reflected in the respective directory being the first element in .libPaths().

When I start "R Interactive" in VS Code, that first element is the default directory, ~/R/x86_64-pc-linux-gnu-library/4.4. Moreover, Sys.getenv("R_LIBS_USER") returns the same. That indicates that the R extension overwrites R_LIBS_USER.

To Reproduce

Set R_LIBS_USER, start VS Code, run "R: Create R terminal", run

.libPaths()
Sys.getenv("R_LIBS_USER")

However, it doesn't reproduce reliably. Sometimes the library specified by R_LIBS_USER is used, sometimes there isn't any user library in .libPaths() at all.

Expected behavior

I expect "R Interactive" to respect the environment variable R_LIBS_USER.

Environment (please complete the following information):

• OS: Debian 12.10
• VSCode Version: 1.98.2
• R Version: 4.4.3
• vscode-R version: 2.8.4

[allefeld]

PS: I tried adding my R library directory to r.libPaths, without effect.

PPS: I forgot to mention that the problem does not occur if R or radian is started outside of VS Code.

[Fred-Wu]

I tried adding my R library directory to r.libPaths, without effect.

You could put R_LIBS_USER = to .Renviron file.

[allefeld]

You could put R_LIBS_USER = to .Renviron file.

Sure. Though I would have to check whether that is actually exempt from the bug. More importantly, reading the setting from an environment variable is documented behavior of R, so imho this is a bug in vscode-R.

[benz0li]

I have a custom library set up for R, by setting R_LIBS_USER in my .bashrc

The R Extension does not source ~/.bashrc, so environment variable R_LIBS_USER is not set to your custom library before it starts R.

imho this is a bug in vscode-R.

No.

[allefeld]

The R Extension does not source ~/.bashrc, so environment variable R_LIBS_USER is not set to your custom library before it starts R.

The R extension does not have to source ~/.bashrc. R_LIBS_USER is part of the environment in which VS Code and therefore the R extension is started.

This environment is still in effect within VS Code, e.g. R_LIBS_USER has the correct value in the Terminal pane, and if I start R or radian within that pane, it is reflected in .libPaths().

It is only in the R extension's "R Interactive" special pane in which – sometimes – this existing environment is ignored.

[benz0li]

The R extension does not have to source ~/.bashrc. R_LIBS_USER is part of the environment in which VS Code and therefore the R extension is started.

You wrote that R_LIBS_USER is set in ~/.bashrc.

This environment is still in effect within VS Code, e.g. R_LIBS_USER has the correct value in the Terminal pane, and if I start R or radian within that pane, it is reflected in .libPaths().

Terminal = Bash = sourcing ~/.bashrc.

It is only in the R extension's "R Interactive" special pane in which – sometimes – this existing environment is ignored.

Set an arbitrary environment variable in ~/.bashrc, e.g. export YOURNAME=allefeld and restart the Terminal.

• Start R/radian from Terminal; Execute Sys.getenv("YOURNAME"); Expected output: [1] "allefeld"
• Start R/radian via Extension; Execute Sys.getenv("YOURNAME"); Expected output: [1] ""

[allefeld]

Okay, it took me a while to understand what you're saying, because I always assumed that upon any login, .bash_profile is executed (if bash is the selected shell), which in my case sources .bashrc, and then all further processes inherit variables exported from there. I now learned that that is not always the case for graphical login, and apparently never for the modern setup based on systemd. Therefore variables defined in .bashrc are not inherited by programs started from the GUI (in my case KDE). I think e.g. the Python extension circumvents that by having a shell script wrapper for the interpreter. At least I never ran into such a problem before.

Workaround: Create a shell script wrapper for R or radian and configure that as the R extension setting r.rterm.linux.