服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

有关多个包pipe理系统的良好做法

一些编程语言自带包pipe理系统,例如,在R的情况下,内置的install.packages命令从CRAN存储库安装并处理相关性。 与此同时,操作系统也有自己的软件包pipe理系统,就像基于debian的Linux发行版的apt命令一样。 我决定使用发行版的包pipe理器来保证我的系统上的所有内容都是兼容的(参见https://stackoverflow.com/a/31293955/1878788 )。 但是不久之后,我需要那些不可用的东西。 例如,一个没有被我的发行包装的生物信息学程序将需要一些特定版本的R.它发生的程序可以通过一个名为“bioconductor”的项目,其目标是提供生物信息学R包,确保包互相兼容(请参阅https://www.bioconductor.org/install/#why-biocLite )。 所以我决定不使用我的OS包装pipe理系统,并通过bioconductor项目提供的biocLite命令安装所有的东西。 这种方法运行平稳一段时间,直到我发现为了保持连贯,健康和易于重build的生物信息学生态系统,一些人决定使用conda包pipe理系统。 这个名为“bioconda”的项目不仅提供R软件包,还提供各种语言的软件,可以轻松切换版本等(请参阅https://bioconda.github.io/ )。 然后,我决定使用这种方法,而且它运行顺利,直到我需要一个不是由bioconda / conda提供的R包。 这应该是非常容易的,但是我制作conda软件包的尝试失败了,于是我尝试用bioconductor的方式安装软件包,但是又失败了。 我有这样的印象,即包装构build机制正在使用错误的R装置。 所以我决定清除我的(还很年轻的)conda安装并返回到我的bioconductor生态系统。 我想知道我将不得不从一种方法跳到另一种方法多久。 关于如何处理这些多重,干扰和重叠的包裹pipe理水平,是否有一般的良好做法? 编辑(14/09/2017) :我考虑的另一个select是使用替代的OS级包pipe理器,如Guix或Nix 。