2011-11-03 14 views
21

Antes de actualizar a R-2.14, quiero aprovechar la oportunidad para racionalizar la estructura de carpetas de mis paquetes instalados.¿Cómo administrar múltiples ubicaciones de paquetes (carpetas) en R?

Por el momento utilizo el valor predeterminado R, es decir, todos los paquetes instalados nuevos van a R_LIBS_USER. Sin embargo, realmente distingo dos clases de paquetes:

  • Paquetes que utilizo repetidamente para hacer mi trabajo, p. plyr, data.table, etc.
  • Paquetes instalo sólo para experimentar con (a menudo a replicar una pregunta o respuesta en StackOverflow)

Desde install.packages ofrece uno la opción de especificar un argumento lib, esto es claramente posible.

¿Existe alguna manera fácil de administrar las ubicaciones de los paquetes, p. creando alguna función sensata de configuración/envoltura en .RProfile o RProfile.Site?

+1

Aquí hay [una Q & A relacionada y útil] (http://stackoverflow.com/questions/2988559/how-do-you-use-multiple-versions-of-the-same-r-package). – Iterator

Respuesta

24

Existen numerosas opciones para eso. Lo primero que hice fue adaptar mi Rprofile.site para que contenga la siguiente línea, haciendo que mi ruta de biblioteca predeterminada sea un directorio no incluido en mi instalación R.

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

Esto hace que D:/R/Library mi ruta predeterminada sin perder las otras rutas. Puede agregar dos rutas a esa, digamos D:/R/Library/Work y D:/R/Library/Test. El que se coloca en la primera posición es el predeterminado utilizado si no especifica lib en install.packages().

Luego puede asignar dos variables en su .Rprofile.site. Estos están asignados en el espacio de nombres base, y por lo tanto siempre son accesibles y no eliminados por ls(). Algo así como

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

que le permite instalar paquetes como:

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

Hay otras opciones también supongo, pero esto es cómo iba a rodar.

+0

+1 Grandes consejos, Joris. –

+3

Una nota de advertencia cuando se usa este enfoque: conduce a complicaciones cuando se intenta verificar/construir/instalar paquetes con 'R CMD comprobar ...'. La razón es que 'R CMD check' y' R CMD build' no lee '.Rprofile' (http://cran.r-project.org/doc/manuals/R-exts.html#Checking-and- building-packages). – Andrie

4

Se supone que debe poder especificar varias rutas/árboles de biblioteca a través de una lista de rutas separadas por dos puntos en la variable ambiental R_LIBS. No pude hacer que esto funcione de manera confiable en R 2.13.1, parcheado, solo toma la primera entrada. Obtuve R_LIBS y R_LIBS_USER para trabajar de manera confiable en mi sistema; normalmente solo configuro el primero.

.libPaths() puede agregar nuevas rutas al conjunto de árboles de la biblioteca que se buscan. Solo agregaría las llamadas apropiadas al .libPaths(new) en mi .Rprofile para agregar los árboles relevantes para cada sesión. Luego puede elegir dónde instalar los paquetes en el momento de la instalación, es decir, qué árbol usar.

+0

La misma experiencia aquí. Es por eso que uso .libPaths() para configurar estos. También porque install.packages() toma el primer valor de .libPaths() como predeterminado. Lo encontré más fácil que jugar con las variables ambientales. –

2

Para responder, tengo que dar un poco de contexto.

Para propósitos de reproducibilidad, intento guiar cosas, incluida toda mi configuración R. Tengo un script "initializeR.r" que, entre otras cosas, instala paquetes, y he organizado paquetes en paquetes, como los relacionados con la caché, los relacionados con la visualización, el muestreo, las estadísticas espaciales, etc. - mi propio pequeño vistas de tareas, si lo desea.

Por ejemplo, aquí es un fragmento:

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

combino algunos de los haces en un paquetes de "mayor" (o primaria) Lista y otros entrar en la lista de "secundaria". Estoy seguro de que instalaré todo en la lista principal; estos son necesarios para tener un entorno R razonable, para usar mis propios scripts, funciones y paquetes, etc. (Por cierto, algunos paquetes se asignan a múltiples paquetes, pero solo unos pocos; Deduzco antes de procesar una lista agregada.)

Luego especifico una biblioteca predeterminada específica de la plataforma, e instálela allí. Sin embargo, esta capacidad es extensible y esta idea se puede ampliar para incluir ubicaciones opcionales para cada paquete de paquete (o paquete): simplemente haga un mapa del nombre del paquete, p. "CodingTools" en un directorio único (ruta de la biblioteca), diga "D:/R/Library/CodingTools". Esto se puede hacer en la secuencia de comandos de inicialización, con las opciones predeterminadas de las listas &, o las ubicaciones se pueden almacenar en otra parte, como una tabla hash, JSON o una base de datos.

Como han dicho otros, las rutas de biblioteca predeterminadas deben comunicarse a R. Esto se puede hacer en .RProfile.site. En mi caso, tengo otro script que se usa para inicializar la instancia R como me gustaría. Intento evitar los archivos de parámetros externos que son leídos por R (por ejemplo, .Rprofile) y, en cambio, hago todas las inicializaciones a través de llamadas a funciones en mi propio paquete (aunque los parámetros todavía son externos). Esto tiende a facilitarme la depuración y reproducción de mi trabajo. Por lo tanto, las rutas de mi biblioteca se pueden incluir en el mismo tipo de JSON donde se especifican las ubicaciones de mis archivos de datos.

Personalmente, quiero alejarme de la definición de los paquetes dentro del script y en su lugar usar JSON, ya que puedo crear más fácilmente diferentes archivos JSON para diferentes configuraciones de configuración. Ya lo hago para la mayoría de los otros propósitos de trabajo reproducible.

Cuestiones relacionadas