-
Notifications
You must be signed in to change notification settings - Fork 30
Description
NB, this issue has previously been discussed at jalvesaq/Vim-R/issues/445.
Problem description
When a project uses {renv}, {nvimcom} is not available, meaning a good deal of R.nvim breaks. The reason for this is that in {renv} projects the .libPaths() are reset, meaning R can no longer find {nvimcom}, which will have been installed by R.nvim into the libpath where most other package installations also live.
Current workaround
The workaround people seem to have been using is to:
- Create a new libpath directory somewhere, e.g. called
nvimcomlib - Create a symlink within this libpath that points to the existing
nvimcominstallation - Set the
RENV_CONFIG_EXTERNAL_LIBRARIESenvironmental variable to point to this new libpath, which tells {renv} it can also look for package installations here
There are a few issues with this workaround:
- You need to go through these steps each time you update R
- Symlinks may be hard to create, e.g. on Windows without admin privileges
- It requires some esoteric knowledge, both about {renv} and R.nvim
Suggested approach for seamless {renv} support
- When R.nvim is installed, instead of dropping {nvimcom} into the user's default libpath directory, keep this package in its own dedicated directory somewhere else
- Then, let R know that it can also look for package installations in this alternative location, e.g. by setting the
R_LIBSenvironmental variable before R starts up - At the same time, set the
RENV_CONFIG_EXTERNAL_LIBRARIESenvironmental variable to the same value, thereby making {nvimcom} available in {renv} projects
I'm not that familiar with with what happens when R.nvim is installed, so I don't know how realistic/well informed this approach is. However, {renv} is pretty widely used - a quick GitHub search reveals 9.1k repos with a renv.lock file - so in my humble opinion, it's worth seriously considering adding official support.