How to manage multiple package locations (folders)

问题:

Before I upgrade to R-2.14, I want to take the opportunity to rationalise the folder structure of my installed packages.

At the moment I use the R default, i.e. all new installed packages goes to R_LIBS_USER. However, I really distinguish between two classes of package:

• Packages I use repeatedly to do my work, e.g. plyr, data.table, etc.
• Packages I install just to experiment with (often to replicate a question or answer on StackOverflow)

Since install.packages offers one the option to specify a lib argument, this is clearly possible.

Is there an easy way to manage package locations, e.g. by creating some sensible settings / wrapper function in .RProfile or RProfile.Site?

回答1:

Hadley's excellent package devtools provides a function dev_mode.
http://www.inside-r.org/packages/cran/devtools/docs/dev_mode

Here you can find an example usage: https://gist.github.com/1150934

Basically,

dev_mode(TRUE, path = "anywhere-you-want-to-install")
install.packages("anything-that-you-want-to-install")

is a powerful way.

回答2:

There are numerous options for that. The first thing I did was adapt my Rprofile.site to contain the following line, making my default library path a directory not included in my R installation.

 .libPaths(c("D:/R/Library",.libPaths()))

This makes D:/R/Library my default path without losing the other paths. You can add two paths to that one, say D:/R/Library/Work and D:/R/Library/Test. The one that's put in the first position is the default one used if you don't specify lib in install.packages().

Then you can assign two variables in your .Rprofile.site. These ones are assigned in the base namespace, and hence always accessible and not removed by ls(). Something like

 .libwork <- 'D:/R/Library/Work'
 .libtest <- 'D:/R/Library/Test'

which allows you to install packages like:

 install.packages('aPackage',lib=.libwork)

There are other options too I guess, but this is how I would roll.

回答3:

You are supposed to be able to specify several library paths/trees via a colon separated list of paths in the Environmental Variable R_LIBS. I couldn't get this to work reliably on R 2.13.1-patched - it only ever takes the first entry. I got R_LIBS and R_LIBS_USER to work reliably on my system - I normally only set the former.

.libPaths() can add new paths to set of library trees searched. I'd just add the appropriate calls to .libPaths(new) in my .Rprofile to add the relevant trees for each session. Then you can choose where to install packages at install time - i.e. which tree to use.

回答4:

To answer, I have to give a bit of context.

For the purposes of reproduceability, I try to script things, including my entire R setup. I have a script "initializeR.r" that, among other things, installs packages, and I've arranged packages in bundles, such as those relating to cacheing, those relating to visualization, sampling, spatial stats, etc. - my own little task views, if you will.

For instance, here is a snippet:

# Profiling & testing
Packages$CodingTools = c("codetools","debug", "profr","proftools","RUnit")

I combine some of the bundles into a "Major" packages (or primary) list and others go into the "Secondary" list. I am sure to install everything on the primary list - these are needed to have a reasonable R environment, to use my own scripts, functions, and packages, etc. (Btw, some packages are assigned to multiple bundles, but only a few; I de-dupe before processing an aggregated list.)

I then specify a platform specific default library, and install to there. However, this capability is extensible and this idea can be extended to include optional locations for each package bundle (or package): just map from bundle name, e.g. "CodingTools" to a unique directory (library path), say "D:/R/Library/CodingTools". This can be done in the initialization script, with matching lists & default options, or the locations could be stored elsewhere, such as a hash table, JSON, or a database.

As others have said, the default library paths need to be communicated to R. That can be done in .RProfile.site. In my case, I have another script that is used to initialize the R instance as I'd like it. I try to avoid external parameter files that are read by R (e.g. .Rprofile), and instead do all initializations via function calls in my own package (though the parameters are still external). This tends to make it easier for me to debug and reproduce my work. So, my library paths can be included in the same kind of JSON where my data file locations are specified.

Personally, I want to get away from defining the bundles inside the script and instead use JSON, as I can more easily create different JSON files for different setup configurations. I already do this for most other purposes of reproducible work.