[Bioc-devel] BiocInstaller: next generation

[Martin Morgan]

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}}