[Bioc-devel] BiocInstaller: next generation

Martin Morgan m@rtin@morg@n @ending from ro@wellp@rk@org
Thu May 10 01:17:25 CEST 2018

On 05/09/2018 07:05 PM, Aaron Lun wrote:
> This all sounds pretty reasonable to me. The ability to choose the
> version in install() is nice, especially if we can easily flip between
> versions in different install locations. I presume that
> version="release" will be the default?

I actually have some reservation about introducing the 'release' synonym 
-- telling a user on April 30 that they should use 'release' and then 
again on May 2 that they should use 'release', but to mean two different 
versions of Bioconductor seems confusing to me. Also the notion that a 
more-or-less casual user will get into Bioconducor enough to grok the 
whole release / devel cycle seems somehow presumptuous. Of course 
developers are a more sophisticated lot, and the notion of a 'devel' 
branch is central to Bioconductor's approach to version management...


> As for the names - BiocManager seems the most sober of the lot. And
> thematically appropriate - you might have an orchestra and conductor,
> but you still need a manager to get everyone paid, fed and on the stage.
> -Aaron
> Martin Morgan wrote:
>> Developers --
>> A preliminary heads-up and request for comments.
>> Almost since project inception, we've used the commands
>>    source("https://bioconductor.org/biocLite.R")
>>    biocLite(pkgs)
>> to install packages. This poses security risks (e.g., typos in the
>> url) and deviates from standard R package installation procedures.
>> We'd like to move to a different system where a base package, call it
>> 'BiocManager', is installed from CRAN and used to install Bioconductor
>> packages
>>    if (!"BiocManager" %in% rownames(installed.packages()))
>>        install.packages("BiocManager")
>>    BiocManager::install(pkgs)
>> This establishes a secure chain from user R session to Bioconductor
>> package installation. It is also more consistent with base R package
>> installation procedures.
>> BiocManager exposes four functions
>>    - install() or update packages
>>    - version() version of Bioconductor in use
>>    - valid() are all Bioconductor packages from the same Bioconductor
>> version?
>>    - repositories() url location for Bioconductor version-specific
>> repositories
>> install() behaves like biocLite(), using the most current version of
>> Bioconductor for the version of R in use. It stores this state using a
>> Bioconductor package 'BiocVersion', which is nothing more than a
>> sentinel for the version in use. One can also 'use devel' or a
>> particular version of Bioconductor (consistent with the version of R)
>> with
>>    BiocManager::install(version = "3.8")   # or the synonym "devel"
>> We intend to phase this in over several release cycles, and to
>> continue to support the traditional biocLite() route for versions
>> before BiocManager becomes available.
>> We also intend to change the overall versioning of 'Bioconductor'
>> itself, where releases are always even (3.8, 3.10, 3.12, ...) and
>> 'devel' always odd.
>> Obviously this is a large change, eventually requiring updates to many
>> locations on our web site and individual vignettes.
>> Of course the key question is the name of the 'BiocManager' package.
>> It cannot easily be 'BiocInstaller', because of the differences in way
>> CRAN and Bioconductor version packages. Some possible names are
>> '
>> BiocInstall::install()
>> BiocPackages::install()
>> BiocManager
>> BiocMaestro
>> Your comments are welcome...
>> Martin
>> This email message may contain legally privileged and/or...{{dropped:2}}
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> _______________________________________________
> The information in this email is confidential and inte...{{dropped:12}}

More information about the Bioc-devel mailing list