Boa prática em relação a vários sistemas de gerenciamento de pacotes

Question

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

Em paralelo, o SO vem com seus próprios sistemas de gerenciamento de pacotes, como o comando apt para distribuições Linux baseadas no Debian.

Eu decidi que era melhor usar o gerenciador de pacotes da distribuição, para garantir que tudo no meu sistema fosse compatível (veja link ).

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 do 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 seja compatível entre si (veja link ).

Decidi não usar meu sistema de gerenciamento de pacotes do SO para o R e instalar tudo por meio do comando biocLite fornecido pelo projeto do biocondutor.

Essa abordagem funcionou sem problemas por algum tempo, até que descobri que para manter ecossistemas de bioinformática coerentes, saudáveis e facilmente reconstruíveis, algumas pessoas decidiram usar o sistema de gerenciamento de pacotes conda. Este projeto, chamado "bioconda", fornece não apenas pacotes R, mas também coisas de todos os tipos de idiomas, com a possibilidade de mudar facilmente de versões, e assim por diante (veja link ).

Então, decidi usar essa abordagem, e ela funcionou sem problemas até que eu precisei de um pacote R que não fosse fornecido pela bioconda / conda. É supostamente super fácil, mas minhas tentativas de fazer um pacote conda falharam, então eu tentei instalar o pacote usando o modo bioconductor, e ele falhou novamente. Tenho a impressão de que, de alguma forma, a instalação errada do R estava sendo usada pelos mecanismos de criação de pacotes. Então eu decidi apagar a minha (ainda muito nova) instalação conda e voltar ao meu ecossistema biocondutor.

Eu estou querendo 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?

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

    

Answer 1

Não tenho certeza do que está disponível para R (ouvi falar sobre o REnv), mas para Python eu decidi sobre a abordagem pragmática de cada usuário ser responsável por seu próprio ambiente Python com pyenv (o mesmo é verdadeiro para Perl com perlbrew e Ruby com RVM ). Dessa forma, os usuários podem criar seu próprio ambiente ideal para cada projeto sem minha assistência ( pyenv gerencia instalações Python e, em seguida, você pode usar pip para instalar módulos locais para essa instalação específica do Python).

Os pacotes do sistema são usados apenas para as necessidades do sistema.

    

Answer 2

Normalmente, é melhor usar o gerenciador de pacotes do sistema. Mas se você estiver usando linguagens modernas, as distribuiçõ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 o gerenciamento de pacotes, seria ótimo, mas o uso de ferramentas não oficiais é um tanto arriscado.