libPath conflict in Ubuntu 22.04 between r2u default site-library and R console and RStudio paths
technocrat opened this issue · comments
I've been struggling a bit with packages that seem to have been successfully downloaded but cannot be found. Another pilgrim surfaced with the same issue on community.rstudio.com. If this is expected behavior, maybe just a README note. Otherwise, please think about it?
As @hunsicker describes his setup
Evidently the system is now installing the compiled R packages into /usr/lib/R/site-library rather than into my personal R library. Since update.packages() looks first in my personal R library, it finds an old version and doesn't look further to see if there is a newer version in the site library. As a result, the package is never effectively updated.
We don't have exactly similar configs. My .libPath looks like
> .libPaths() [1] "/home/roc/R/x86_64-pc-linux-gnu-library/4.2" [2] "/usr/local/lib/R/site-library" [3] "/usr/local/lib/R/library"
and r2u is installing to /usr/lib/R/site-library.
Is it just a matter of linking everything in .libPaths to that directory, or is it better to fiddle with env and profile to set things right?
That is likely a different issue going straight back to r-base-core (which of course I maintain too).
In short, R Core changed something just before 4.2.0 and I tried to adapt, the adaptation is not perfect, and I just discussed this one R Core member and should have something better.
In short, and per background, the use of
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library" "/usr/lib/R/library"
> under Debian (and Ubuntu) goes back to a (very constructive) discussion two R Core members and I had ... 20 years! In short the first for what you do locally, the other two are for what the distro does in package with the final one for R's base + recommended packages.
In Debian we (used to) set his via /etc/R/Renviron / etc/R/Renviron.site. This just worked. Then R 4.2.0 made a change and all of sudden we had a difference between R -q -e '.libPaths() and R --vanilla -q -e '.libPaths()'. I suspect that is what is going on here.
So can you show me what Rscript -e .libPaths() and Rscript --vanilla -e .libPaths() show?
I now have this (improved !!) behavior:
edd@rob:~$ Rscript -e '.libPaths()'
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library" "/usr/lib/R/library"
edd@rob:~$ Rscript --vanilla -e '.libPaths()'
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
edd@rob:~$ You get this by a) having nothing in Renviron.site (where you could per-user directories, I personally prefer without) and b) have this in Renviron:
#R_LIBS_USER=${R_LIBS_USER:-'%U'}
#R_LIBS_SITE=${R_LIBS_SITE:-'%S'}
## On Debian set the system-wide package library we promot as a system-level
## library while allowing users to set R_LIBS_USER if they want to
R_LIBS_USER=${R_LIBS_USER:-'%U'}
R_LIBS_SITE=${R_LIBS_SITE:-'/usr/local/lib/R/site-library:%S'}
Now, of course, r2u being binaries and apt packages, they should go into /usr/lib/R/site-library -- and the bigger question is why do you exclude /usr/lib/R ? What made you do so?
Also, what @hunsicker describes is standard R behavior. "User knows best" so user directory comes first, and R trusts it. r2u has nothing to do with that -- if the user "decides to" or "happens to" hide packages there is exactly nothing r2u can do.
Thanks for the diagnosis (user-itis, an inflammatory response to things not going perfectly to misconception). The key well-duh is that r2u is an accessory to apt, so naturally it defaults to the system library. Probably compounded by this user getting impatient for the usual sources to update R and doing it manually. (More fool me.) I'll have to double my contribution to the coffee fund.
Ok -- good if this is sorted out. The library path is obviously very important and not something one want to get wrong.