Bonne pratique concernant plusieurs systèmes de gestion de paquets

Certains langages de programmation sont livrés avec leur propre système de gestion de packages, par exemple, dans le cas de R, la install.packagescommande intégrée s'installe à partir du référentiel CRAN et gère les dépendances.

En parallèle, les systèmes d'exploitation sont livrés avec leurs propres systèmes de gestion de paquets, comme la aptcommande pour les distributions Linux basées sur Debian.

J'avais décidé qu'il valait mieux utiliser le gestionnaire de paquets de la distribution, afin de garantir que tout sur mon système serait compatible (voir /programming//a/31293955/1878788 ).

Mais un jour est venu où j'avais besoin de choses qui n'étaient pas disponibles de cette façon. Par exemple, un programme de bioinformatique qui n'était pas conditionné par ma distribution nécessiterait une version spécifique de R. Il est arrivé que le programme soit disponible via un projet nommé "bioconducteur", dont l'objectif était de fournir des packages R pour la bioinformatique, garantissant que les packages seraient être compatibles les uns avec les autres (voir https://www.bioconductor.org/install/#why-biocLite ).

J'ai donc décidé de ne pas utiliser mon système de gestion de packaging OS pour R, et de tout installer via la biocLitecommande fournie par le projet bioconducteur.

Cette approche s'est déroulée sans heurts pendant un certain temps, jusqu'à ce que je découvre que pour maintenir des écosystèmes bioinformatiques cohérents, sains et facilement reconstructibles, certaines personnes avaient décidé d'utiliser le système de gestion de paquets conda. Ce projet, appelé "bioconda" fournit non seulement des packages R, mais des choses de toutes sortes de langages, avec la possibilité de changer facilement de version, etc. (voir https://bioconda.github.io/ ).

J'ai alors décidé d'utiliser cette approche à la place, et cela s'est bien passé jusqu'à ce que j'aie besoin d'un package R qui n'était pas fourni par bioconda / conda. C'est censé être super facile, mais mes tentatives pour créer un package conda ont échoué, puis j'ai essayé d'installer le package en utilisant la méthode du bioconducteur, et il a échoué à nouveau. J'ai l'impression qu'en quelque sorte la mauvaise installation de R était utilisée par les mécanismes de construction de paquets. J'ai donc décidé d'effacer mon (encore très jeune) installation de conda et de retourner dans mon écosystème bioconducteur.

Je me demande combien de temps je vais devoir passer d'une approche à l'autre. Existe-t-il des bonnes pratiques générales concernant la manière de gérer ces niveaux multiples, interférents et chevauchants de gestion des packages?

Edit (14/09/2017) : Encore une autre option que j'ai envisagée est d'utiliser des gestionnaires de packages alternatifs au niveau du système d'exploitation, comme Guix ou Nix .

Je ne sais pas ce qui est disponible pour R (entendu parler de REnv), mais pour Python, j'ai décidé de l'approche pragmatique selon laquelle chaque utilisateur est responsable de son propre environnement Python avec pyenv(il en va de même pour Perl avec perlbrewet Ruby avec RVM). De cette façon, les utilisateurs peuvent créer leur propre environnement optimal pour chaque projet sans mon aide ( pyenvgère les installations Python et vous pouvez ensuite utiliser pippour installer des modules locaux à cette installation Python spécifique).

Les packages système ne sont utilisés que pour les besoins du système.

Il est généralement préférable d'utiliser le gestionnaire de packages système. Mais si vous utilisez des langages modernes, qui évoluent rapidement, les distributions stables n'incluront pas de nouveaux packages et de nouvelles versions. Et les packages pas si populaires ne peuvent jamais être inclus dans les référentiels.

Je dirais donc que la meilleure façon dans ce cas est d'utiliser les fonctions intégrées du langage. Si les R-créateurs créeront un outil officiel pour gérer les packages, ce serait bien, mais utiliser des outils non officiels est quelque peu risqué.