[R-sig-Debian] /etc/R/Renviron doesn't set R_LIBS_USER anymore

Dirk Eddelbuettel edd at debian.org
Mon Jul 3 14:18:36 CEST 2017


On 3 July 2017 at 13:05, Ramon Diaz-Uriarte wrote:
| If I might chime in, I'd like to add my vote to the "users should be able
| to use install.packages and should be able to install bioconductor
| packages with biocLite".
| 
| Longer story
| ============
| 
| Two cases (I've just faced this morning), where
| /usr/local/lib/R/site-library/ was not user-writeable:
| 
| 1. Students using Debian or Ubuntu on their laptops, where these students
| are not particularly knowledgeable about Linux.
| 
| 2. Sys admins that install and configure software for computer labs, where
| beyond some bare minima (e.g., R, gcc, etc) users are expected and allowed
| to install (some) software on their homes. These sys admins might be
| specially reluctant to add users to privileged groups and/or make
| /usr/local/lib/R/site-library user-writeable.
| 
| The problem is that both groups, after issuing the
| 
| sudo apt-get install r-base
| sudo apt-get install r-base-dev
| 
| (as per https://cran.r-project.org/bin/linux/ubuntu/README.html)
| 
| are later surprised when users cannot immediately install packages in the
| "usual R way (install.packages)".  And this gets more complicated when we
| add a bunch of bioconductor packages, where BioConductor pages often say to
| install as
| 
| source("https://bioconductor.org/biocLite.R")
| biocLite(some_packages)
| 
| I've ended up doing
| 
| .libPaths(c(the_user_home, .libPaths()))
| 
| but this does not look very friendly for new users.

Easier: Remove one # comment character in /etc/R/Renviron which does the same.

As does setting in file /etc/R/Renviron.site (which the package never
touches).

And local policy can (and should!) still be to set a local group.
 
Dirk 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org



More information about the R-SIG-Debian mailing list