Question: BiocInstaller fails to load with older R within a 'suppressMessages()' context
gravatar for Kevin Ushey
3.1 years 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(), "//"))
  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")
        sink(con, type = "message")
            fcon <- file("")
            on.exit(close(fcon), add = TRUE)
            readLines(fcon, 1L)
        }, error = function(e) {
        sink(type = "message")
        useHTTPS <- length(readLines(fl)) == 0L
        PROTOCOL <<- if (useHTTPS) 
        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.



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

[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       
biocinstaller • 700 views
ADD COMMENTlink modified 3.0 years ago by Martin Morgan ♦♦ 24k • written 3.1 years 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 3.1 years ago by Kevin Ushey10
Answer: BiocInstaller fails to load with older R within a 'suppressMessages()' context
gravatar for Martin Morgan
3.0 years ago by
Martin Morgan ♦♦ 24k
United States
Martin Morgan ♦♦ 24k 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 3.0 years ago by Martin Morgan ♦♦ 24k

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:

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?


ADD REPLYlink written 3.0 years 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 3.0 years ago by Martin Morgan ♦♦ 24k
Please log in to add an answer.


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