Buenas prácticas con respecto a los sistemas de gestión de paquetes múltiples.

Algunos lenguajes de programación vienen con su propio sistema de gestión de paquetes, por ejemplo, en el caso de R, el install.packagescomando incorporado se instala desde el repositorio de CRAN y se ocupa de las dependencias.

Paralelamente, el sistema operativo viene con sus propios sistemas de gestión de paquetes, como el aptcomando para distribuciones de Linux basadas en Debian.

Decidí que era mejor usar el administrador de paquetes de la distribución para garantizar que todo en mi sistema fuera compatible (consulte /programming//a/31293955/1878788 ).

Pero pronto llegó un día en que necesitaba cosas que no estaban disponibles de esta manera. Por ejemplo, un programa de bioinformática que no fue empaquetado por mi distribución requeriría una versión específica de R. Sucedió que el programa estaba disponible a través de un proyecto llamado "bioconductor", cuyo objetivo era proporcionar paquetes R para bioinformática, asegurando que los paquetes ser compatibles entre sí (ver https://www.bioconductor.org/install/#why-biocLite ).

Así que decidí no usar mi sistema de gestión de empaquetado del sistema operativo para R e instalar todo a través del biocLitecomando proporcionado por el proyecto de bioconductor.

Este enfoque funcionó sin problemas durante algún tiempo, hasta que descubrí que para mantener ecosistemas bioinformáticos coherentes, saludables y fácilmente reconstruibles, algunas personas habían decidido utilizar el sistema de gestión de paquetes de conda. Este proyecto, llamado "bioconda", proporciona no solo paquetes R, sino también cosas de todo tipo de lenguajes, con la posibilidad de cambiar fácilmente las versiones, etc. (ver https://bioconda.github.io/ ).

Entonces decidí usar este enfoque, y funcionó sin problemas hasta que necesité un paquete R que no fue proporcionado por bioconda / conda. Supuestamente es súper fácil, pero mis intentos de hacer un paquete conda fallaron, luego traté de instalar el paquete usando la forma de bioconductor, y falló nuevamente. Tengo la impresión de que de alguna manera los mecanismos de construcción de paquetes estaban utilizando una instalación R incorrecta. Así que decidí borrar mi (aún muy joven) instalación de conda y volver a mi ecosistema bioconductor.

Me pregunto cuánto tiempo tendré que saltar de un enfoque a otro. ¿Hay buenas prácticas generales sobre cómo lidiar con estos niveles múltiples, interferentes y superpuestos de gestión de paquetes?

Editar (14/09/2017) : Otra opción que consideré es usar administradores de paquetes alternativos a nivel del sistema operativo, como Guix o Nix .

No estoy seguro de lo que está disponible para R (escuché sobre REnv), pero para Python he decidido el enfoque pragmático con el que cada usuario es responsable de su propio entorno Python pyenv(lo mismo es cierto para Perl con perlbrewy Ruby con RVM). De esa manera, los usuarios pueden crear su propio entorno óptimo para cada proyecto sin mi ayuda ( pyenvadministra las instalaciones de Python y luego puede usarlo pippara instalar módulos locales para esa instalación específica de Python).

Los paquetes del sistema solo se usan para las necesidades del sistema.

Por lo general, es mejor usar el administrador de paquetes del sistema. Pero si está utilizando lenguajes modernos, los desarrollos rápidos y estables no incluirán nuevos paquetes y versiones. Y los paquetes no tan populares nunca se pueden incluir en los repositorios.

Entonces diría que la mejor manera en ese caso es usar las funciones integradas del lenguaje. Si R-creators creara una herramienta oficial para administrar paquetes, sería genial, pero usar herramientas no oficiales es algo arriesgado.