迁移R库

Question

我想要将 Linux 上的几个 R 库 (*) 从一个驱动器移动到另一个驱动器，想知道是否可以简单地移动并且安全，或者我应该卸载并重新安装这些包。我意识到库的位置通过 .libPaths() 进行标识，并查看了 "R Installation and Administration" 手册以了解如何迁移库，但没有看到推荐的过程。

我认为有三个选项：

1. 对于所有非基础包运行 remove.packages()，然后通过 install.packages(lib = "/path/to/new/location") 进行新安装。
2. 使用 mv 移动库（目录），并使用符号链接指向新位置（最终删除符号链接）。
3. 使用 Linux 中的 mv 命令批量移动目录并在 R Installation and Administration 手册 中建议的 R_HOME/etc/Rprofile.site 中更新 .Library.site。

选项 #1 很粗糙。选项 #2 应该可行，但似乎有点不可靠。

选项 #3 是否安全，或者存在严重问题？我发现的问题是：目录权限和任何软件包的设置存储绝对路径而不是相对路径的可能性（这似乎不可靠且不必要）。

关于绝对路径的存储，我发现rJava将R_HOME的位置存储在一个名为run的文件中。这并不是一个库问题本身，但它表明一个包（一个好的包）保留了绝对路径的私有副本。

(*) 有几个库和许多包。自然地，只移动了库（目录），但是可能会影响到包。

---

更新1 / 澄清：仅迁移库，不更改R的版本或软件包的版本。更新R或软件包可以单独完成，但问题只是移动库是否可行。如果需要更新或重新安装所有软件包以确保正确安装，则这更类似于选项＃1而不是选项＃3。

更新2：另一个SO帖子的答案提供了一些避免升级时出现此问题的好方法。我不是在升级R，但Dirk Eddelbuettel建议不要在R的文件树中安装软件包是明智的。

- Iterator

---

我不确定你要做什么，但你可能想看一下这个问题及其相关内容。 - Fred

+1 如果你知道库和包的区别 :-) - Ari B. Friedman

@gsk3：希望我修复了所有可能出现的这种错误。我不想因为这样一个术语问题而遭到严厉批评。:) - Iterator

@Fred：+1 - 可移植性是一个不同的问题，但是，如果没有其他问题，关于可移植性和完全自包含的安装的讨论使我意识到我应该保留所有软件包源代码。这将使得在卸载和重新安装时确保版本相同变得非常简单。 - Iterator

Answer 1

选择方案3（将旧库复制到新库）应该可以解决问题...但前提是您之后运行：

update.packages(checkBuilt=TRUE)

以这种方式，需要为新版本重新构建的软件包将会被更新。通常情况下，新版本会添加要求（例如2.14.x版本中即将添加的NAMESPACE要求）。

编辑：看到这只是在重新安排甲板上的椅子……如果您正在移动任何基本的R安装，我会放弃支持#3。这对我在Mac上起作用，但我没有在R安装和管理指南或R FAQ中看到它应该起作用的承诺。您可以通过以下步骤完成＃1（在各种条件下可能是最安全的）：

# 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.

如果您安装了最新版本的R，并将.Libpaths设置为您的首选项（甚至可以是相同的旧安装）：

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

如果R可执行文件没有更改，只需将软件包移至新库可能会成功（假设您还更改了.Libpaths），但我没有Linux安装来测试它或知道由配置操作设置的任何指针会受到影响。

- IRTFM

---

谢谢，这很有趣。您能澄清三件事吗：（1）在“需要为新版本重新构建”中提到的版本是指R，对吗？（2）如果（1）正确，那么如果软件包不需要重新构建（即它比当前版本的R旧），会发生什么？（3）当您说“当且仅当”时，我理解为这是一个必要且充分的条件...您真的是这个意思吗？ :) 如果是这样，那么我可能还没有理解为什么会这样。我并不反对，但这个选项对我来说是新的，我还没有掌握逻辑。 - Iterator

（1）是的。例如，从R 2.13.x更改为R 2.14.x，其中x可以是0、1或2。据我所知，简单地复制可能会导致一个新的主要版本的功能包，例如从2.13到2.14的更改，但这绝不是保证。所以我可能太绝对了。“应该工作”意味着将检查软件包在版本上的依赖关系，如果您不进行update.packages，则不会运行任何检查。 - IRTFM

然而，如果我只是移动目录 而不是升级 R，那么这样做有什么好处吗？ - Iterator

另一种表述方式是：如果没有互联网连接，那么这种方法似乎存在问题。选项#3不需要互联网连接，但#1需要。然而，我现在意识到，如果我重新安装或进行大规模更新，保留所有源代码可能会更有益。 - Iterator

这听起来像是最安全的解决方案。此外，当我保存软件包源代码时，我可以提高一切可重现性的可能性。 - Iterator

Answer 2

结合被接受的答案和这个, 我找到了一个更简单的解决方案:

lib_loc <- "C:/Users/apdev/Documents/R/win-library/3.3"
to_install <- unname(installed.packages(lib.loc = lib_loc)[, "Package"])
to_install
remove.packages(to_install, lib="C:/Users/apdev/Documents/R/win-library/3.3")
install.packages(pkgs = to_install, lib="C:/Program Files/R/R-3.6.1/library")

- Rodrigo Coelho