He encontrado este problema varias veces, y no puedo encontrar ninguna solución, sino trivial (ver a continuación).Método seguro para actualizar paquetes R: ¿es posible el intercambio en caliente?
Supongamos que una computadora está ejecutando más de 2 instancias de R, debido a más de 2 usuarios o 1 usuario que ejecuta procesos múltiples, y una instancia ejecuta update.packages(). He tenido varias ocasiones en las que la otra instancia puede ser criticada a lo grande. Los paquetes que se actualizan no cambian la funcionalidad de ninguna manera que afecte el cálculo, pero de alguna manera surge un gran problema.
La solución trivial (Solución 0) es terminar todas las instancias de R mientras se ejecuta update.packages(). Esto tiene más de 2 problemas. Primero, uno tiene que terminar instancias R En segundo lugar, es posible que ni siquiera se pueda identificar dónde se están ejecutando esas instancias (ver actualización 1).
Suponiendo que el comportamiento del código que se está ejecutando no cambiará (por ejemplo, las actualizaciones de paquetes son beneficiosas; solo corrigen errores, mejoran la velocidad, reducen la RAM y otorgan unicornios), ¿hay alguna manera de intercambiar en caliente un nueva versión del paquete con menos impacto en otros procesos?
Me quedan dos soluciones candidatas, fuera de R:
Solución 1 es utilizar una ruta de la biblioteca temporal y elimine la antigua biblioteca antigua y mover el nuevo en su lugar. El inconveniente de esto es que elimina + movimientos puede incurrir en algún tiempo durante el cual nada está disponible.
La solución 2 consiste en utilizar enlaces simbólicos para apuntar a una biblioteca (o jerarquía de bibliotecas) y simplemente sobrescribir un enlace simbólico con un puntero a una nueva biblioteca donde reside el paquete actualizado. Parece que eso implica menos tiempo de inactividad del paquete, el tiempo que le lleva al SO sobrescribir un enlace simbólico. La desventaja de esto es que requiere mucho más cuidado en la administración de enlaces simbólicos, y es específico de la plataforma.
Sospecho que la solución # 1 podría ser modificado para ser como # 2, mediante un uso inteligente de .libPaths(), pero esto parece que uno tiene que no llamada update.packages() y en lugar de escribir un nuevo actualizador que encuentra los paquetes obsoletos, instalaciones a una biblioteca temporal, y luego actualiza las rutas de la biblioteca. La ventaja de esto es que se podría limitar un proceso existente para la .libPaths() que tenía cuando comenzó (es decir, el cambio de las rutas de biblioteca R conoce acerca de que podría no ser propagada a aquellos casos que ya están ejecutando, sin alguna intervención explícita dentro de esa instancia).
Actualización 1. En el caso de ejemplo, las dos instancias R competidoras están en la misma máquina. Esto no es un requisito: por lo que entiendo las actualizaciones, si las dos comparten las mismas bibliotecas, es decir, los mismos directorios en una unidad compartida, entonces la actualización aún puede causar problemas, incluso si la otra instancia de R está en otra máquina . Entonces, uno podría matar accidentalmente un proceso R y ni siquiera verlo.
Se trata de una punto importante. Sospecho que el problema de una biblioteca compartida es un problema en todos los sistemas operativos. Para la mayoría del uso, me inclino a creer que esto mata la idea de hotswapping. El caso más estricto sería para los paquetes que no utilizan bibliotecas compartidas externas, pero no estoy seguro de cómo funciona para los paquetes que están completamente en R. – Iterator
. Creo que su respuesta aplasta el sueño de hotswapping en general. Incluso si tengo un paquete R puro que me gustaría intercambiar, no es una buena práctica suponer que puedo hacer esto. Vincent tiene una respuesta razonable de cómo se puede hacer versiones, en lugar de intercambiar, lo cual tendré que adaptar bastante, pero está claro que esa es la única forma de evitar los conflictos que has señalado. – Iterator