2011-08-20 10 views
24

Me gustaría mover varias bibliotecas R (*) de una unidad a otra, en Linux, y me gustaría saber si un simple movimiento es factible y seguro o si debería desinstalar y volver a instalar los paquetes. Me doy cuenta de que las ubicaciones de las bibliotecas se identifican a través del .libPaths() y he consultado el manual "R Instalación y administración" para obtener información acerca de la migración de bibliotecas, pero no veo un proceso recomendado.Migrando bibliotecas R

que perciben tres opciones:

  1. Run remove.packages() para todos los paquetes que no son de base, e instalar de nuevo a través de install.packages(lib = "/path/to/new/location").
  2. mover las bibliotecas (directorios) utilizando mv y utilizar enlaces simbólicos para apuntar a las nuevas ubicaciones (y eventualmente eliminar el enlace simbólico)
  3. Utilice el comando mv en Linux para mover los directorios al por mayor y actualizar .Library.site en R_HOME/etc/Rprofile.site, como se sugiere en el R Installation and Administration manual

La opción n. ° 1 es contundente. La opción n. ° 2 debería funcionar, pero parece un poco incorrecta.

¿Es seguro el # 3 o hay serios problemas con él? Los problemas que he identificado son: permisos de directorio y la posibilidad de que la configuración de cualquier paquete almacene rutas absolutas en lugar de rutas relativas (lo cual parece poco sólido e innecesario).

En cuanto al almacenamiento de rutas absolutas, encontré que rJava almacena la ubicación de R_HOME en un archivo llamado run. Esto no es un problema de biblioteca per se, pero es una indicación de un paquete (y un buen paquete) que mantiene una copia privada de una ruta absoluta.

(*) Hay varias bibliotecas y muchos puntajes de paquetes. Naturalmente, solo se mueven las bibliotecas (directorios), pero los paquetes podrían verse afectados.


ACTUALIZA 1/Aclaración: Solo para aclarar: Soy sólo bibliotecas que migran, sin cambiar la versión de R o las versiones de los paquetes. La actualización de R o los paquetes se puede hacer por separado, pero la pregunta es si mover las bibliotecas es factible o no. Parece que si es necesario actualizar o reinstalar todos los paquetes para asegurarse de que las cosas estén instaladas correctamente, entonces esa es una ruta más parecida a la opción n. ° 1 que la opción n. ° 3.

ACTUALIZACIÓN 2: Las respuestas a another SO post tienen algunas buenas ideas sobre cómo evitar este problema al actualizar. No estoy actualizando R, pero la sugerencia de Dirk Eddelbuettel de no instalar paquetes en el árbol de archivos de R es acertada.

+1

No estoy seguro exactamente de lo que está tratando de hacer, pero es posible que desee consultar [esto] (http://stackoverflow.com/questions/5721942/making-r-installation-self-contained-user-independent/6709445 # 6709445) pregunta y relacionado en eso. – Fred

+0

+1 para saber la diferencia entre una biblioteca y un paquete :-) –

+0

@ gsk3: Espero haber arreglado todos los posibles errores de ese tipo. No quiero ser embrutecido por un tema tan terminológico. :) – Iterator

Respuesta

23

Opción # 3 (la copia de la biblioteca antigua a la nueva biblioteca) debería funcionar ... pero si y sólo si a continuación, ejecuta:

update.packages(checkBuilt=TRUE) 

De esta manera los paquetes que necesitan ser reconstruidos para las nuevas versiones serán estar actualizado A menudo ocurre que las nuevas versiones agregan requisitos (como el requisito inminente en 2.14.x para NAMESPACEs).

Editar: Al ver esto solo se mueve alrededor de las sillas de cubierta ... Voy a dejar de apoyar el # 3 si está moviendo cualquiera de la instalación de la base R.Me ha funcionado en una Mac, pero no he visto una promesa en la Guía de instalación y administración de R o en las Preguntas frecuentes de R que debería funcionar en. Esto se puede hacer # 1 (que es probablemente más seguro en diversas condiciones) por esta secuencia:

# In original installation, get the non-default package list: 
save.pkg.list <- installed.packages()[is.na(installed.packages()[ , "Priority"]), 1] 
save(save.pkg.list, file="pkglist.Rdata") 
# If you want to use remove.packages() at this point it's fine. 
# Or just delete their directories. 

Con una versión recién instalada de R con los .Libpaths fijados a sus preferencias (o incluso la misma instalación de edad):

load("pkglist.Rdata") 
install.packages(save.pkg.list) 

sólo mover los paquetes a una nueva biblioteca si los ejecutables R no se cambió podría tener éxito (suponiendo que también cambiar la .Libpaths), pero no tengo una instalación de Linux para probarlo o no saben cómo los punteros establecidos por las operaciones de configuración se verían afectadas.

+0

Gracias, esto es interesante. ¿Puedes aclarar 3 cosas: (1) La mención de versiones en "necesita ser reconstruido para nuevas versiones", esto se refiere a R, ¿correcto? (2) Si (1) es correcto, ¿qué sucede si el paquete no necesita ser reconstruido (es decir, es más antiguo que la versión actual de R)? (3) Cuando dices si y solo si, interpreto que quiere decir que es una condición necesaria y suficiente ... ¿realmente lo dices en serio? :) Si es así, me puede estar perdiendo algo acerca de por qué ese es el caso. No estoy en desacuerdo, pero esta opción es nueva para mí y aún no entiendo la lógica. – Iterator

+0

(1) Sí, es decir, un cambio de R 2.13.x a R 2.14.x donde x puede ser 0, 1 o 2. Según tengo entendido, el simple acto de copiar _might_ da como resultado un paquete funcional para una nueva versión principal, por ejemplo un cambio de 2.13 a 2.14, pero de ninguna manera estaría garantizado. Entonces probablemente fui demasiado categórico. El "debería funcionar" significa que habrá una verificación de las dependencias del paquete en la versión y si no hace una actualización.paquetes, entonces no se ejecutará ninguna verificación. –

+0

Sin embargo, si solo estoy moviendo los directorios * y no actualizando R *, entonces, ¿esto haría algún bien? – Iterator