BiocInstaller fails to load with older R within a 'suppressMessages()' context
1
0
Entering edit mode
Kevin Ushey ▴ 130
@kevin-ushey-5913
Last seen 3.0 years ago
United States

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       
biocinstaller • 1.5k views
ADD COMMENT
0
Entering edit mode

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

ADD REPLY
0
Entering edit mode
@martin-morgan-1513
Last seen 5 days ago
United States

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 COMMENT
0
Entering edit mode

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 REPLY
0
Entering edit mode

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

ADD REPLY

Login before adding your answer.

Traffic: 918 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6