bli*_*bli 14 linux package-management
一些编程语言带有自己的包管理系统，例如，在 R 的情况下，内置install.packages命令从 CRAN 存储库安装并处理依赖项。
同时，操作系统带有自己的包管理系统，例如apt基于 debian 的 Linux 发行版的命令。
我决定最好使用发行版的包管理器，以保证我系统上的所有内容都兼容（参见/sf/answers/2190576881/）。
但很快有一天，我需要用这种方式无法获得的东西。例如，一个没有被我的发行版打包的生物信息学程序需要一些特定版本的 R。碰巧这个程序可以通过一个名为“bioconductor”的项目获得，该项目的目标是为生物信息学提供 R 包，确保包彼此兼容（参见https://www.bioconductor.org/install/#why-biocLite）。
所以我决定不使用我的 OS 打包管理系统 R，并通过biocLitebioconductor 项目提供的命令安装所有东西。
这种方法顺利运行了一段时间，直到我发现为了保持连贯、健康和易于重建的生物信息学生态系统，有些人决定使用 conda 包管理系统。这个名为“bioconda”的项目不仅提供 R 包，还提供各种语言的东西，可以轻松切换版本等（请参阅https://bioconda.github.io/）。
然后我决定改用这种方法，它运行得很顺利，直到我需要一个 bioconda/conda 没有提供的 R 包。据说它非常容易，但是我尝试制作 conda 包失败了，然后我尝试使用 bioconductor 方式安装该包，但它再次失败。我的印象是包构建机制以某种方式使用了错误的 R 安装。所以我决定删除我（还很年轻）的 conda 安装并回到我的 bioconductor 生态系统。
我想知道从一种方法跳到另一种方法需要多长时间。关于如何处理这些多重、相互干扰和重叠的包管理级别，是否有一般的良好做法？
Sve*_*ven 14
我不确定 R 有什么可用（听说过 REnv），但对于 Python，我决定采用务实的方法，每个用户都负责他们自己的 Python 环境pyenv（对于 Perl withperlbrew和 Ruby with也是如此RVM）。这样，用户可以在没有我帮助的情况下为每个项目创建自己的最佳环境（pyenv管理 Python 安装，然后您可以使用pip该特定 Python 安装的本地模块安装）。
系统包仅用于系统需要。