Question: BiocInstaller fails to load with older R within a 'suppressMessages()' context
0
2.9 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))
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")
}, error = function(e) {
message(conditionMessage(e))
})
sink(type = "message")
flush(con)
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       
biocinstaller • 686 views
modified 2.9 years ago by Martin Morgan ♦♦ 23k • written 2.9 years ago by Kevin Ushey10

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

Answer: BiocInstaller fails to load with older R within a 'suppressMessages()' context
0
2.9 years ago by
Martin Morgan ♦♦ 23k
United States
Martin Morgan ♦♦ 23k 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.

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