一些编程语言带有自己的包管理系统，例如，对于 R 来说，内置install.packages命令从 CRAN 存储库安装并处理依赖项。
同时，操作系统带有自己的包管理系统，例如apt基于 debian 的 Linux 发行版的命令。
我决定最好使用该发行版的包管理器，以保证我的系统上的所有内容都兼容（请参阅https://stackoverflow.com/a/31293955/1878788）。
但很快有一天我需要的东西就无法通过这种方式获得。例如，我的发行版没有打包一个生物信息学程序，它需要某个特定版本的 R。碰巧的是，这个程序可以通过一个名为“bioconductor”的项目获得，该项目的目标是为生物信息学提供 R 包，确保包之间相互兼容（参见https://www.bioconductor.org/install/#why-biocLite）。
因此我决定不使用我的操作系统打包管理系统来管理 R，而是通过biocLitebioconductor 项目提供的命令来安装所有内容。
这种方法运行了一段时间，直到我发现，为了维护连贯、健康且易于重建的生物信息学生态系统，有些人决定使用 conda 包管理系统。这个名为“bioconda”的项目不仅提供 R 包，还提供各种语言的包，并且可以轻松切换版本等（请参阅https://bioconda.github.io/）。
然后我决定改用这种方法，它运行得很顺利，直到我需要 bioconda/conda 未提供的 R 包。据说它非常简单，但我尝试制作 conda 包失败了，然后我尝试使用 bioconductor 方式安装包，结果再次失败。我觉得包构建机制不知何故使用了错误的 R 安装。所以我决定删除我的（仍然很新的）conda 安装并返回我的 bioconductor 生态系统。
我想知道我需要花多长时间才能从一种方法跳到另一种方法。有没有关于如何处理这些多重、相互干扰和重叠的包管理级别的一般良好做法？
答案1
我不确定 R 有什么可用（听说过 REnv），但对于 Python，我决定采用务实的方法，即每个用户都对自己的 Python 环境负责（对于 Perl和 Ruby 也是pyenv如此）。这样，用户可以为每个项目创建自己的最佳环境，而无需我的帮助（管理 Python 安装，然后您可以使用它来安装特定 Python 安装本地的模块）。perlbrewRVMpyenvpip
系统包仅用于系统需要。
答案2
通常最好使用系统包管理器。但是如果你使用的是发展迅速的现代语言，稳定的发行版将不会包含新的包和版本。而不太流行的包永远不会包含在存储库中。
所以我认为，在这种情况下，最好的方法是使用语言的内置函数。如果 R 创作者能创建用于管理软件包的官方工具，那就太好了，但使用非官方工具则有点冒险。