有关多个包装管理系统的良好实践

某些编程语言带有其自己的程序包管理系统，例如，对于R而言，内置install.packages命令从CRAN存储库安装并处理依赖项。

同时，OS带有自己的软件包管理系统，例如apt基于debian的Linux发行版的命令。

我已经决定最好使用发行版的软件包管理器，以确保系统上的所有内容都兼容（请参阅/programming//a/31293955/1878788）。

但是很快有一天，我需要用这种方式无法获得的东西。例如，我的发行版未打包的生物信息学程序将需要R的某些特定版本。碰巧该程序可通过名为“ bioconductor”的项目获得，该项目的目的是为生物信息学提供R软件包，以确保软件包将彼此兼容（请参阅https://www.bioconductor.org/install/#why-biocLite）。

因此，我决定不对R使用OS打包管理系统，biocLite而是通过bioconductor项目提供的命令安装所有内容。

这种方法运行了一段时间，直到我发现要维护连贯，健康且易于重建的生物信息学生态系统，有人决定使用conda软件包管理系统。这个名为“ bioconda”的项目不仅提供R包，而且还提供来自各种语言的内容，并且可以轻松切换版本，等等（请参阅https://bioconda.github.io/）。

然后，我决定改用这种方法，并且运行平稳，直到我需要由bioconda / conda未提供的R包为止。据说这非常容易，但是我制作conda包装的尝试失败了，然后我尝试使用生物导体方法安装该包装，但再次失败了。我的印象是，软件包构建机制在某种程度上使用了错误的R安装。因此，我决定删除我（仍然很年轻）的conda安装，然后回到我的生物导体生态系统。

我想知道从一种方法跳到另一种方法需要多长时间。是否有关于如何处理包装管理的多个，干扰和重叠级别的通用良好实践？

编辑（14/09/2017）：我考虑的另一种选择是使用替代的OS级软件包管理器，例如Guix或Nix。

我不确定R是否可以使用（听说过REnv），但是对于Python，我已经决定了务实的方法，即每个用户都要对自己的Python环境负责pyenv（对于Perl perlbrew和Ruby，也是如此RVM）。这样，用户可以在没有我帮助的情况下为每个项目创建自己的最佳环境（pyenv管理Python安装，然后您可以pip用来安装该特定Python安装本地的模块）。

系统软件包仅用于系统需求。

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

所以我想说，在这种情况下，最好的方法是使用语言的内置函数。如果R-creators将创建用于管理软件包的官方工具，那将是不错的选择，但是使用非官方工具会有些冒险。