[Bioc-devel] BiocInstaller fails to load with older R if messages suppressed

(Sorry about cross-posting, but I didn't receive a response at
https://support.bioconductor.org/p/88777/)

---

BiocInstaller incorrectly detects https support if loaded within a
'suppressMessages()' context, and that failure leads to a namespace
load failure on versions of R without libcurl support. To reproduce,
try running the following on a version of R without libcurl (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 issue seems to come from the implementation of
'BiocInstaller:::.protocol', which 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()' may query 'BiocInstaller::biocinstallRepos()',
and a user calling 'packrat::snapshot()' wrapped in
'suppressMessages()' will then see the BiocInstaller load error.

Is there any chance the implementation here could be modified to
instead just set up a local `withCallingHandlers` check, to ensure
that a parent `withCallingHandlers` usage doesn't interefere? Or
something similar?

Thanks,
Kevin