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 ?