RStudio environment when opened under Nvim-R is different

[a-torgovitsky]

I am using the gurobi package in R, which depends on having some environment variables set correctly so that the linked libraries can be found.

I have checked that I can load the library after starting R in any of the following ways:

• command line R
• command line rstudio
• open RStudio through the GUI (Linux Mint 19.2)
• open vim or nvim via the command line, start RStudio through Nvim-R
• open GVim or NeoVimGTK via the command line, start RStudio through Nvim-R

However, if I try to open GVim through the GUI and then start RStudio through Nvim-R, I get the following error:

Error: package or namespace load failed for ‘gurobi’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/at/R/x86_64-pc-linux-gnu-library/3.6/gurobi/libs/gurobi.so':
  libgurobi90.so: cannot open shared object file: No such file or directory

The fact that the paths are correct when I load RStudio through the GUI, and that the paths are correct when I load RStudio through Nvim-R via a GVim editor opened in the terminal leads me to think that there's something about how Nvim-R is transmitting paths as the intermediary. Is that possible? Any idea how I can go about debugging this further?

[jalvesaq]

You could call Sys.getenv("PATH") in either R or RStudio to know what is the PATH there.

-- Jakson Alves de Aquino http://www.posgradsoc.ufc.br/en/professors/jakson-aquino/

[a-torgovitsky]

Thanks, that's helpful. The PATHs are slightly different, but not in a way that would affect finding gurobi.

Just to be sure, I took the path from the RStudio instance that can load gurobi and used it to change the path in the RStudio instance loaded through the GUI and Nvim-R via Sys.setenv(PATH = <path>). However, I still have the problem of the missing libraries.

I also checked both the GUROBI_HOME, LD_LIBRARY_PATH, and GRB_LICENSE_FILE variables in both instances of RStudio, and they are identical in both.

Then I tried Sys.getenv() in both instances to get a full list of environment variables. They are indeed much different in the working and non-working instances. I scanned both, but I am not sure where to focus on for discrepancies that may cause this.

Any other ideas?

[jalvesaq]

I'm sorry, but I don't have any other idea of what could be causing the problem.

[jalvesaq]

When you start an application using a desktop launcher, only the ~/.profile script has been sourced. When you launch an application from the terminal, the ~/.bashrc script (if your shell is bash) has been sourced too. So, perhaps you are defining in your ~/.bashrc environment variables required to run your package.

[a-torgovitsky]

Both my ~/.profile and ~/.bashrc load the same environment variables from a third file.

I compared the environment variables in Sys.getenv() in the working and non-working instance. These are the ones that are different in the two:

_
COLORTERM
INSIDE_NEMO_PYTHON
LESSCLOSE
LESSOPEN
LS_COLORS
NVIMR_ID
NVIMR_SECRET
OLDPWD
PATH
PWD
R_SESSION_TMPDIR
RS_PPM_FD_READ
RS_PPM_FD_WRITE
RSTUDIO_SESSION_PORT
SHLVL
VTE_VERSION
WINDOWID

The only one of these that sticks out to me as potentially problematic is of course PATH.

The PATH in both the good (terminal) and bad (gvim via GUI) instances have the same entries, but in the good case, some of the entries are repeated. I expect this is because of my strategy of sourcing environment variables from a third file. However, having repeated entries in PATH shouldn't be a problem should it? In any case, I also tried setting PATH manually in the bad instance and this did not affect behavior.

[jalvesaq]

For the PATH environment variable, repetition is not a problem, but the order matters. An application is executed from the first directory where it is found in the PATH.

[a-torgovitsky]

Hmm, and yet when I manually set PATH in the bad instance to be the same as it is in the good instance, I still get this behavior. Unfortunately, the gurobi R source code does not appear to be available, otherwise I could poke around in there for clues.

[jalvesaq]

Did you try:

1. Uninstall the gurobi package from R.

2. "Open GVim through the GUI and then start RStudio through Nvim-R" and, then, install the gurobi package again.

This would ensure that it was installed in the same environment where you want to use it.

[a-torgovitsky]

I tried it and the install went successfully. But then I had the same behavior when trying to load the package.

[jalvesaq]

Nvim-R is being superseded by R.nvim, a new project that will be inaugurated in a week at the R-nvim organization. Please, check out tmp-Nvim-R and help us to find the last remaining bugs before R.nvim inauguration. When the project is officially started, you will be able to open issues there and request new features.

Nvim-R will remain alive as a feature-frozen project for Vim users. If you want to know the reason, please, see this discussion.