[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...

Martin

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