r - 更新 R 包的安全方法 - "hot-swapping"可能吗？

Question

我遇到过几次这个问题，除了一个微不足道的解决方案(见下文)之外，我无法找到任何解决方案。

假设一台计算机正在运行 2+ 个 R 实例，由于 2+ 个用户或 1 个用户运行多个进程，并且一个实例执行 update.packages() .我曾经有过几次其他实例可能会被严重破坏的情况。正在更新的包不会以任何影响计算的方式更改功能，但不知何故会出现一个大问题。

简单的解决方案(解决方案 0)是在 update.packages() 时终止所有 R 实例。执行。这有2个以上的问题。首先，必须终止 R 实例。其次，人们甚至可能无法识别这些实例在哪里运行(参见更新 1)。

假设正在执行的代码的行为不会改变(例如，包更新都是有益的——它们只会修复错误、提高速度、减少 RAM 并授予 unicorn )，是否有某种方法可以热交换新版本的包对其他流程的影响更小？

在 R 之外，我还有两个候选解决方案:

解决方案 1 是使用临时库路径，然后删除旧的旧库并将新库移动到它的位置。这样做的缺点是删除 + 移动可能会导致一段时间内没有可用的内容。

解决方案 2 是使用符号链接(symbolic link)指向库(或库层次结构)，然后用指向更新包所在的新库的指针覆盖符号链接(symbolic link)。这似乎会导致更少的程序包停机时间 - 操作系统覆盖符号链接(symbolic link)所需的时间。这样做的缺点是它在管理符号链接(symbolic link)时需要更加小心，并且是特定于平台的。

我怀疑解决方案 #1 可以通过巧妙地使用 .libPaths() 修改为类似于 #2。 , 但这似乎不需要调用 update.packages()而是编写一个新的更新程序来查找过时的软件包，将它们安装到临时库中，然后更新库路径。这样做的好处是可以将现有进程限制为 .libPaths()它在启动时就有(即更改 R 知道的库路径可能不会传播到那些已经在运行的实例，而无需对该实例进行一些明确的干预)。

更新 1. 在示例场景中，两个竞争的 R 实例位于同一台机器上。这不是必需的:据我了解更新，如果两者共享相同的库，即共享驱动器上的相同目录，那么更新仍然会导致问题，即使 R 的另一个实例在另一台机器上.所以，一个人可能会不小心杀死一个 R 进程，甚至看不到它。

Answer 1

在生产环境中，您可能希望至少保留两个版本，即当前版本和以前的版本，以便在出现问题时能够快速切换回旧版本。什么都不会被覆盖或删除。对于整个 R 生态系统来说，这样做更容易:你会有几个目录，比如“R-2.14.1-2011-12-22”、“R-2.14.1-2012-01-27”等，每个都包含所有内容(R 可执行文件和所有包)。这些目录永远不会更新:如果需要更新，将创建一个新目录。 (某些文件系统提供“快照”，允许您拥有许多非常相似的目录，而不会过度使用磁盘空间。)

从一个版本切换到另一个版本可以在用户端完成，当用户启动 R 时，或者通过将 R 可执行文件替换为使用正确版本的脚本，或者通过将其 PATH 环境变量设置为指向所需版本。这可确保给定 session 始终看到相同版本的所有内容。