多包管理系统的良好做法

Question

一些编程语言附带了自己的包管理系统，例如，在R中，内置的install.packages命令从CRAN存储库中安装，并处理依赖关系。

同时，OS还附带了自己的包管理系统，比如基于debian的Linux发行版的apt命令。

我已经决定最好使用发行版的包管理器，以保证我的系统上的所有内容都是兼容的(参见https://stackoverflow.com/a/31293955/1878788)。

但很快就有一天，我需要用这种方式买不到的东西。例如，我的发行版没有打包的生物信息学程序需要一些特定版本的R。碰巧，该程序是通过一个名为“生物导体”的项目提供的，该项目的目标是为生物信息学提供R包，确保软件包彼此兼容(参见https://www.bioconductor.org/install/#why-biocLite)。

因此，我决定不使用我的操作系统包装管理系统的R，并安装所有通过biocLite命令提供的生物导体项目。

这种方法运行了一段时间，直到我发现为了保持连贯、健康和易于重建的生物信息学生态系统，一些人决定使用conda软件包管理系统。这个项目名为"bioconda“，它不仅提供了R包，还提供了各种语言的东西，可以轻松切换版本，等等(参见https://bioconda.github.io/)。

然后我决定用这个方法代替，它运行顺利，直到我需要一个没有由生物协和/conda提供的R包。它被认为是超级容易，但我试图制造一个conda软件包失败了，然后我试图安装使用生物导体的方式，它再次失败。我的印象是，不知怎的，错误的R安装是使用包装建设机制。因此，我决定删除我的(仍然非常年轻) conda安装，回到我的生物导体生态系统。

我想知道我要从一种方法跳到另一种方法需要多长时间。对于如何处理这些多重、干扰和重叠的包管理级别，是否有一般的良好做法？

编辑(14/09/2017)：我考虑过的另一种选择是使用其他操作系统级别的包管理器，如瓜瓦或尼克斯。

Answer 1

通常最好使用系统包管理器。但是，如果您使用的是现代语言，那么快速、稳定的发行版将不会包括新的包和版本。而不那么受欢迎的软件包永远不可能包含在存储库中。

所以我想说，在这种情况下最好的方法是使用语言的内置函数。如果R-创建者将创建管理软件包的官方工具，那就太好了，但是使用非官方工具有点风险。