[Bioc-devel] BiocInstaller: next generation

James W. MacDonald jm@cdon @ending from uw@edu
Fri May 18 15:32:25 CEST 2018

On Fri, May 18, 2018 at 3:28 AM, Neumann, Steffen <sneumann at ipb-halle.de>

> 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.
> 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 completely disagree with this idea. We have spent almost two decades now
trying to enforce the idea that we provide a coherent set of packages that
are guaranteed at some level to interoperate correctly. And biocLite was
the way we provided that. People have always had the opportunity to use
install.packages directly, or just go to the website and download any
package version they might like. Changing that now, to (in some sense)
officially allow people to install whatever versions they like is IMO both
short sighted and against the whole idea of having a coherent set of

It's not really difficult (like, at all) to install whatever version of
package you might want, but making it easy for naive users to mix-n-match
doesn't make any sense to me at all.



> i.e. a package from a given BioC release, or a specific version
> of a package, regardless from which release it comes.
> 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.
> 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
> --
> IPB Halle                    AG Massenspektrometrie & Bioinformatik
> Dr. Steffen Neumann          http://www.IPB-Halle.DE
> Weinberg 3                   http://msbi.bic-gh.de
> 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
>                                   +49 (0) 345 5582 - 0
> sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

James W. MacDonald, M.S.
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

	[[alternative HTML version deleted]]

More information about the Bioc-devel mailing list