Some programming languages come with their own package management system, for instance, in the case of R, the built-in install.packages command installs from the CRAN repository and deals with dependencies.

In parallel, OS come with their own package management systems, like the apt command for debian-based Linux distributions.

I had decided that it was better to use the distribution's package manager, in order to guarantee that everything on my system would be compatible (see https://stackoverflow.com/a/31293955/1878788).

But soon came a day when I needed things that were not available this way. For instance, a bioinformatics program that was not packaged by my distribution would require some specific version of R. It happened that the program was available through a project named "bioconductor", whose goal was to provide R packages for bioinformatics, ensuring that packages would be compatible with one another (see https://www.bioconductor.org/install/#why-biocLite).

So I decided not to use my OS packaging management system for R, and install everything through the biocLite command provided by the bioconductor project.

This approach ran smoothly for some time, until I discovered that to maintain coherent, healthy and easily rebuildable bioinformatics ecosystems, some people had decided to use the conda package management system. This project, called "bioconda" provides not only R packages, but things from all sorts of languages, with the possibility to easily switch versions, and so on (see https://bioconda.github.io/).

I then decided to use this approach instead, and it ran smoothly until I needed an R package that was not provided by bioconda/conda. It is supposedly super easy, but my attempts at making a conda package failed, then I tried to install the package using the bioconductor way, and it failed again. I have the impression that somehow the wrong R installation was being used by the package building mechanisms. So I decided to erase my (still very young) conda installation and go back to my bioconductor ecosystem.

I'm wondering how long I will have to jump from one approach to another. Are there general good practice regarding how to deal with these multiple, interfering, and overlapping levels of package management ?

Edit (14/09/2017): Yet another option I considered is to use alternative OS-level package managers, like Guix or Nix.


2 Answers 2


I am not sure what is available for R (heard about REnv), but for Python I've decided on the pragmatic approach that every user is responsible for their own Python environment with pyenv (same is true for Perl with perlbrew and Ruby with RVM). That way, users can create their own optimal environment for every project without my assistance (pyenv manages Python installations and then you can use pip to install modules local to that specific Python installation).

System packages are only used for system needs.


Usually it is better to use system package manager. But if you are using modern languages, that evolve fast, stable distributives won't include new packages and versions. And not-so-popular packages can never be included in repositories.

So I'd say, the best way in that case is using language's built-in functions. If R-creators will create official tool for managing packages, it would be great, but using non-official tools is somewhat risky.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .