[Bioc-devel] BiocInstaller: next generation
On 05/18/2018 03:28 AM, Neumann, Steffen wrote:
Hi, On Wed, 2018-05-09 at 18:11 -0400, Martin Morgan wrote:
...
- version() version of Bioconductor in use
- valid() are all Bioconductor packages from the same
Bioconductor
version?
I'd like to challenge the concept of the release and the pretty strong term valid(). I think BioC is the only R package repository that has the release concept, and this is good to have a consistent well tested environment of packages for a given R version. It is also great to pick the most recent package version within a release for installation, but that also prevents installing a package newer than the one tied to the R version at hand. But R already has the concept of versioned dependencies, so in theory we wouldn't /need/ the release concept.
The version management in R itself is not up to this task, e.g., there is no transparent way to install archived packages and their dependencies https://hypatia.math.ethz.ch/pipermail/r-help/2018-May/454482.html or to manage multiple versions of a single package https://support.bioconductor.org/p/108656/#108965 in base R. There is no discipline amongst package developers to manage dependencies either initially or over the long tenure of a package in Bioconductor. This is not helped by open-ended promises like 'Biobase (>= x.y.z)', which is a very optimistic statement about the backward compatibility of future versions of Biobase. So theory and practice are unfortunately diverged.
I'd like to suggest to make it easier to shoot yourself into the foot by installing less tested combinations
of R and BioC packages, and to support installing BiocManager::install(X, version=0.8.15) BiocManager::install(X, release=3.8) BiocManager::install(X, release=devel) i.e. a package from a given BioC release, or a specific version of a package, regardless from which release it comes.
I guess there are so many ways to shoot oneself in the foot that it is a wonder that we still have feet! I'm with Jim on this one...
The valid() is a bit unspecific name, what is probably meant here is BiocManager::tainted(), which indicates that packages come from different BioC versions, and all hell might break loose and it'll eat your kittens.
...and a minor thing is that striving for the positive result of valid()
is more appealing than the negative of tainted().
And a plug for some feature creep I introduced the other day
BiocManager::available("BSgenome.*(musculus|sapiens)")
Martin
This also means that Package developers would ask for the tainted() status in bug reports, and (c|sh)ould refuse help for unsupported combination. It also means that packagers would have to be more careful with the versioned dependencies, and supply minimal versions. If they give a versioned dependency on the Biobase, they essentially forbid installing on old BioC releases, which would be fine. Just my 2c, Yours, Steffen
This email message may contain legally privileged and/or...{{dropped:2}}