Hi, As comments are welcome I will give my two cents and a patch suggestion :-)
2017-07-06 10:42 GMT+02:00 Dirk Eddelbuettel <e...@debian.org>: > > > I have used such settings (such as un-setting R_LIBS_USER or its > predecessors) for over a decade, it just works (if you give write > permissions). It clearly helps us at work because everybody sees by > the default the same packages. I have also spoken with different R > Core members and several find the default installation below $HOME and > in a versioned directory less than ideal as well. But it ensures > writeability. Which I cannot do easily from the package. > > > So maybe the change was too abrupt, and I think I may revert it. I > generally prefer for packagers like myself to not divert from upstream > unless they have good reasom or are unintrusive (and eg the added > tab-completion we have here is both). But leaving newbies without > installable directories is bad, as is possibly hiding existing > installations. There are several entangled issues: 1. What should be the default places where packages are installed? 2. What should be the default places where packages are loaded from? 3. Ensuring that with the default R installation any user can install packages For 1., I believe packages should be installed at: - /usr/lib/R/library, if they are given by a .deb package (core R packages) - /usr/lib/R/site-library/, if they are given by a .deb package (other packages) - /usr/local/lib/R/site-library/, if the user has permissions - ~/R/x86_64-pc-linux-gnu-library/3.4, (or somewhere else under $HOME, otherwise) For 2., I believe packages should be loaded from: - ~/R/x86_64-pc-linux-gnu-library/3.4 - /usr/local/lib/R/site-library/ - /usr/lib/R/site-library/ - /usr/lib/R/library I believe with 3.4.1-1 Dirk tried to move towards that configuration, and for some reasons we ended in a situation where the R library in the HOME directory was not considered to write into and was not considered to load packages from. This is how R works: - When we use `library("package_name")`, the package_name is searched in the directories given by .libPaths(). - When we use `install.packages("package_name")`, by default the package is installed in the first element of .libPaths(). These two things make it very tricky to find a solution to 1, because: - We can't change .libPaths() as we would break with how packages are searched - We may try to change install.packages() so instead of trying to install to .libPaths()[1] by default it tries /usr/local/lib/R/site-library first. We don't know how many things may break because they rely on that assumption, we would need to test CRAN packages like checkpoint and packrat and worse we don't know if we break some custom setups from users. - We can't remove the home directory from .libPaths() because some users won't be able to install packages there anymore nor find their packages, unless they choose to do that in their Renviron file. Considering this, the safest approach is to remove the home directory approach from .libPaths() as Dirk tried to do. The main problem is that there the personal directory approach failed and there was not enough documentation in install.packages() to fix that. Maybe a help message in install.packages would have helped. I attach a DEP-3 compliant patch as a proposal. It works on my computer. I'm no expert so your review is very welcome. The patch does a small change in how install.packages works: If the package can't be installed into .libPaths()[1] (/usr/local/lib/R/site-library/), and if the user directory is NA (because it is not set anymore in /etc/Renviron) then: * the default user directory is used instead: ~/R/%p-library/%v * and "Would you like to use \\n~/R/%p-library/%v \nto in the future to install packages into?" is asked. if the answer is "yes", then it is appended to the ~/.Renviron file. > > I am a little pressed for time (at useR!) and system (main server is > ill, as is backup machine) but I should get a 3.4.1-2 out. > I hope this helps, I am missing the useR conference, I hope I can assist next year :-) Best, Sergio _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian