On 05/11/2018 03:33 AM, Lluís Revilla wrote:
Dear Bioconductor team,

Bioconductor packages can be installed via install.packages when they are a dependency of another package if there is in the DESCRIPTION file a "biocViews:" section (see https://github.com/r-lib/devtools/issues/700#issuecomment-235127291 <https://github.com/r-lib/devtools/issues/700#issuecomment-235127291>) . I don't know how install.packages handles these packages in Bioconductor but would it be possible to use this trick to directly install the packages in Bioconductor?

biocLite() actually user install.packages(). the 'trick' is to have the correct 'repos' argument. In essence that is what biocLite() / BiocManager::install() does -- sets the repository argument to include the location where Bioconductor version x is available for R version y.

Users of base R can `setRepositories()`; then install.packages() installs Bioconductor packages. The problem is that the version of Bioconductor installed by this approach is hard-coded in R, so the user gets the version of Bioc available at the time of the release of R, rather than the most recent version available for their version of R. After setRepositories() and selecting all bioc options, in my 'devel' install I have

> getOption("repos")
                                                   CRAN
                                               "@CRAN@"
                                               BioCsoft
           "https://bioconductor.org/packages/3.7/bioc";
                                                BioCann
"https://bioconductor.org/packages/3.7/data/annotation";
                                                BioCexp
"https://bioconductor.org/packages/3.7/data/experiment";

whereas I actually want

> BiocManager::repositories()
                                               BioCsoft
           "https://bioconductor.org/packages/3.8/bioc";
                                                BioCann
"https://bioconductor.org/packages/3.8/data/annotation";
                                                BioCexp
"https://bioconductor.org/packages/3.8/data/experiment";
                                          BioCworkflows
      "https://bioconductor.org/packages/3.8/workflows";
                                                   CRAN
                             "https://cran.rstudio.com";


install.packages() does not pay attention to biocViews; the comment you reference is incorrect (here's the sole reference to 'biocViews' in the R source code: https://github.com/wch/r-source/blob/3137a19986dfa547eba59b46ed8dc02b0dbf888c/src/library/tools/R/utils.R#L1249)


What will happen with BiocInstaller package? The package has the same description and purpose of the proposed new package. Wouldn't be better to move this new functionality to BiocInstaller and move it to CRAN?

Package names need to be unique across CRAN and Bioconductor, so there can only be one BiocInstaller. BiocInstaller as it exists in Bioconductor supports two different interfaces to package management already ('legacy' biocLite, plus more recent BiocInstaller::biocLite()) and has 15 years of code; it is better to start with a clean implementation.

Martin

Best,

Lluís



On 10 May 2018 at 00:11, Martin Morgan <martin.mor...@roswellpark.org <mailto:martin.mor...@roswellpark.org>> 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
    <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@r-project.org <mailto:Bioc-devel@r-project.org> mailing list
    https://stat.ethz.ch/mailman/listinfo/bioc-devel
    <https://stat.ethz.ch/mailman/listinfo/bioc-devel>




This email message may contain legally privileged and/or...{{dropped:2}}

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to