Boas práticas em relação a vários sistemas de gerenciamento de pacotes

Algumas linguagens de programação vêm com seu próprio sistema de gerenciamento de pacotes, por exemplo, no caso do R, o install.packagescomando interno é instalado a partir do repositório CRAN e lida com dependências.

Paralelamente, o SO vem com seus próprios sistemas de gerenciamento de pacotes, como o aptcomando para distribuições Linux baseadas em debian.

Decidi que era melhor usar o gerenciador de pacotes da distribuição, para garantir que tudo no meu sistema fosse compatível (consulte /programming//a/31293955/1878788 ).

Mas logo chegou o dia em que eu precisava de coisas que não estavam disponíveis dessa maneira. Por exemplo, um programa de bioinformática que não foi empacotado pela minha distribuição exigiria uma versão específica de R. Aconteceu que o programa estava disponível através de um projeto chamado "biocondutor", cujo objetivo era fornecer pacotes R para bioinformática, garantindo que os pacotes ser compatíveis entre si (consulte https://www.bioconductor.org/install/#why-biocLite ).

Decidi não usar o sistema de gerenciamento de pacotes do SO para R e instalar tudo através do biocLitecomando fornecido pelo projeto do biocondutor.

Essa abordagem funcionou sem problemas por algum tempo, até que eu descobri que, para manter ecossistemas de bioinformática coerentes, saudáveis ​​e de fácil reconstrução, algumas pessoas decidiram usar o sistema de gerenciamento de pacotes conda. Este projeto, chamado "bioconda" fornece não apenas pacotes R, mas coisas de todos os tipos de idiomas, com a possibilidade de alternar facilmente versões e assim por diante (consulte https://bioconda.github.io/ ).

Decidi então usar essa abordagem e ela funcionou sem problemas até precisar de um pacote R que não fosse fornecido pelo bioconda / conda. É supostamente super fácil, mas minhas tentativas de criar um pacote conda falharam; tentei instalar o pacote usando o caminho do biocondutor e falhou novamente. Tenho a impressão de que, de alguma forma, a instalação incorreta do R estava sendo usada pelos mecanismos de criação de pacotes. Por isso, decidi apagar minha instalação de condomínio (ainda muito jovem) e voltar ao meu ecossistema de biocondutores.

Gostaria de saber quanto tempo terei que pular de uma abordagem para outra. Existem boas práticas gerais sobre como lidar com esses níveis múltiplos, interferentes e sobrepostos de gerenciamento de pacotes?

Editar (14/09/2017) : Outra opção que considerei é usar gerenciadores de pacotes alternativos no nível do SO, como Guix ou Nix .

Não sei ao certo o que está disponível para o R (ouvi falar do REnv), mas para o Python eu decidi pela abordagem pragmática com a qual cada usuário é responsável por seu próprio ambiente Python pyenv(o mesmo vale para o Perl perlbrewe o Ruby RVM). Dessa forma, os usuários podem criar seu próprio ambiente ideal para cada projeto sem minha assistência ( pyenvgerencia instalações do Python e, em seguida, você pode usar pippara instalar módulos locais para a instalação específica do Python).

Pacotes de sistema são usados ​​apenas para as necessidades do sistema.

Geralmente é melhor usar o gerenciador de pacotes do sistema. Mas se você estiver usando linguagens modernas, essas evoluções rápidas e estáveis ​​não incluirão novos pacotes e versões. E pacotes não tão populares nunca podem ser incluídos em repositórios.

Então, eu diria que a melhor maneira nesse caso é usar as funções internas da linguagem. Se os criadores de R criarem uma ferramenta oficial para gerenciar pacotes, seria ótimo, mas o uso de ferramentas não oficiais é um pouco arriscado.