Search
Question: BiocInstaller fails to load with older R within a 'suppressMessages()' context
0
gravatar for Kevin Ushey
12 months ago by
Kevin Ushey10
United States
Kevin Ushey10 wrote:

To reproduce, try running the following code on a version with R without libcurl support (e.g. the Snow Leopard build of R 3.2.1):

> suppressMessages(library(BiocInstaller))
Error : .onLoad failed in loadNamespace() for 'BiocInstaller', details:
  call: url(paste0(.protocol(), "//bioconductor.org/BiocInstaller.dcf"))
  error: https:// URLs are not supported
Error: package or namespace load failed for ‘BiocInstaller’

The interaction occurs when 'BiocInstaller:::.protocol' attempts to ascertain whether `https://` or `http://` should be used. The implementation has:

        con <- file(fl <- tempfile(), "a")
        on.exit(close(con))
        sink(con, type = "message")
        tryCatch({
            fcon <- file("https://bioconductor.org/index.html")
            on.exit(close(fcon), add = TRUE)
            readLines(fcon, 1L)
        }, error = function(e) {
            message(conditionMessage(e))
        })
        sink(type = "message")
        flush(con)
        useHTTPS <- length(readLines(fl)) == 0L
        PROTOCOL <<- if (useHTTPS) 
            "https:"
        else "http:"

And that attempt to populate a message sink fails when executed within a suppressMessages() context. Although the above example is artificial, most other examples may not be -- it's easy to imagine that the BiocInstaller namespace might be implicitly loaded deep within the bowels of some code; for example, 'packrat::snapshot()' will query 'BiocInstaller::biocinstallRepos()', and a user calling 'packrat::snapshot()' wrapped in 'suppressMessages()' will then see the BiocInstaller load error.

There are a lot of safer ways this check for https could be implemented:

1. Attempt to read a URL with known contents, and check for expected output.
2. Check 'capabilities("libcurl")'.
3. Check for a specific version of R.

Thanks,
Kevin

---

> sessionInfo()
R version 3.2.1 (2015-06-18)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
Running under: OS X 10.12 (unknown)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] utils   methods base   

loaded via a namespace (and not attached):
[1] BiocInstaller_1.20.3 graphics_3.2.1       tools_3.2.1          grDevices_3.2.1      stats_3.2.1       
ADD COMMENTlink modified 12 months ago by Martin Morgan ♦♦ 20k • written 12 months ago by Kevin Ushey10

I believe .onLoad failed in loadNamespace() for 'BiocInstaller' is related (although a reproducible example was not discovered there).

ADD REPLYlink written 12 months ago by Kevin Ushey10
0
gravatar for Martin Morgan
12 months ago by
Martin Morgan ♦♦ 20k
United States
Martin Morgan ♦♦ 20k wrote:

Hi Kevin -- I've been digesting this and should have replied earlier. First the use of sink was 'necessary' because of the way that version of R handled failed connections (via message or print rather than warning / error). Second, that version of Bioconductor is frozen and won't be changed. Third, the current check does not need to and so does not use sink (see BiocInstaller::.protocol). And finally, I guess the code is an attempt at 1. (try the connection); 2. is inadequate in general because e.g., on my Linux libcurl("capabilities") simply returns TRUE without additional information about https support; 3. is not sufficient because the version of R does not determine https support. I believe that there is code in RStudio that tests for https support, but I've lost track of where that is, so any info would be appreciated.

ADD COMMENTlink written 12 months ago by Martin Morgan ♦♦ 20k

Hi Martin,

Thanks for the response -- it looks like the current development version of BiocInstaller should indeed resolve this particular issue.

For reference, RStudio attempts to force the use of https on startup by taking over the 'download.file.method' and 'download.file.extra' options. The logic is a bit complicated, but lives here:

https://github.com/rstudio/rstudio/blob/3dff46a66359df96a01e247a4a8a99c26cc1a5e2/src/cpp/session/modules/SessionPackages.R#L974-L1032

Put briefly, if we have a recent-enough version of R alongside libcurl support compiled in, then we'll attempt to use libcurl; otherwise, we'll check for 'curl' or 'wget' on the PATH and use those if possible (and assume they 'know' how to handle https). We make these changes only if the user hasn't opted in to their own options for these (e.g. set in a .Rprofile or something similar).

Perhaps I'm misunderstanding something, but wouldn't the presence of libcurl support imply that libcurl could be used as a downloader for https links?

Thanks,
Kevin

ADD REPLYlink written 12 months ago by Kevin Ushey10

libcurl can be compiled without ssl support; this could be accidental (e.g., ssl library not found at libcurl install time) or intentional.

ADD REPLYlink written 12 months ago by Martin Morgan ♦♦ 20k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.2.0
Traffic: 150 users visited in the last hour