Description
I have a vanilla installation of Windows (no proxies or anything similar) where remotes::install_github("yihui/testit")
won't work (it fails similarly for many other packages that do and don't require compilation). I've tried the two most recent patched versions of R (3.4.3 and 3.4.4) and both the CRAN and GitHub master version of remotes (the CRAN version predates the most recent changes to install-github.R). It's been throwing this error for at least a week.
Furthermore, these same arrangements have been working fine on my other Windows machines. And working fine on this same machine with devtools::install_github("yihui/testit")
. The error message is
> remotes::install_github("yihui/testit")
Downloading GitHub repo yihui/testit@master
Error in utils::download.file(url, path, method = download_method(), quiet = quiet, :
cannot open URL 'https://api.github.com/repos/yihui/testit/zipball/master'
Stepping through after declaring debug(utils::download.file)
leads to the following misbehaving line, and I don't have the skills to debug once it cross the R-C boundary.
.External(C_download, url, destfile, quiet, mode, cacheOK, method == "wininet")
I'm not seeing anything similar amoung the 18 SO hits. Is this something I should ask SO about instead? I'm not that worried for my own case, because I can keep using devtools::install_github()
, but as more people migrate to remotes, this corner case might cause more problems.
traceback
> traceback()
11: utils::download.file(url, path, method = download_method(), quiet = quiet,
mode = "wb")
10: withCallingHandlers(expr, warning = function(w) invokeRestart("muffleWarning"))
9: suppressWarnings(status <- utils::download.file(url, path, method = download_method(),
quiet = quiet, mode = "wb"))
8: base_download(real_url, path, quiet)
7: download(dest, src, auth_token = x$auth_token)
6: remote_download.github_remote(remote, quiet = quiet)
5: remote_download(remote, quiet = quiet)
4: FUN(X[[i]], ...)
3: vapply(remotes, install_remote, ..., FUN.VALUE = logical(1))
2: install_remotes(remotes, ...)
1: remotes::install_github("yihui/testit")
session info
R version 3.4.4 Patched (2018-03-19 r74446)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.4 tools_3.4.4 yaml_2.1.18 remotes_1.1.1
Activity
gaborcsardi commentedon Mar 31, 2018
This is coming from
utils::download.file
so either that does not support HTTPS, or you need a GH API token because your IP address was rate limited, or some other error, like a bad proxy setup.Unfortunately there is not much we can do about it in remotes, other than maybe trying to a different download method, or try multiple methods.
But for that we would need to be able to recreate your problem, so some questions:
gh::gh("/rate_limit")
utils::download.file()
directly, with the same URL?utils::download.file()
methods?wibeasley commentedon Apr 4, 2018
Your intuition was right. It appears to be influenced by the 'method' parameter in
utils::download.file()
.method="libcurl"
option worked. All others failed.What would be helpful for me to do next?
'method' values that fail
cderv commentedon Apr 4, 2018
In
remotes::install_github
, the download method is determined byremotes::download_method()
and set to"auto"
except on older R version. On windows, it is not libcurl by defaut but wininet when auto is set.FWIW, I can't reproduce the issue on my windows computer, but I am on windows 10.
Could it come from a different behaviour of wininet between different version of windows?
I will try to verify that.
One solution could be to check for libcurl availability by default but it was the previous behaviour that did not allowed windows proxy behavior offered by wininet.
Reprex
with defaults
with wininet explicitly
with auto from
remotes:::download_method()
Created on 2018-04-04 by the reprex package (v0.2.0).
Session info
gaborcsardi commentedon Apr 4, 2018
@wibeasley I suspect that this is a TLS issue, GitHub does not support TLS v1 and v1.1
See e.g. https://githubengineering.com/crypto-deprecation-notice/
Older Windows systems only support TLS v1.x, so the system's builtin HTTP lib does not work with GitHub. It is possible that you can enable TLS v1.2 or you can download a patch from MS. E.g. https://cloudblogs.microsoft.com/microsoftsecure/2017/07/20/tls-1-2-support-added-to-windows-server-2008/
It depends on your windows version.
To make this more robust, remotes could try a couple of methods, at least on windows trying
libcurl
andwininet
would make sense.wibeasley commentedon Apr 4, 2018
I don't mind doing that or either of the two other solutions (eg, specifying "libcurl", or calling
devtools::install_github()
). But these may not be feasible to expect otherremotes::install_github()
users to do without a lot of problems encountered.If you think I have a weird computer failing on a trivial issue, I'm happy to drop the issue. Or, if you think I have a canary in a coalmine, I'm happy to provide more info to help make
remotes::install_github()
more robust. I'm cool with whatever you feel is the best use of your time.In case this helps create a more dynamic/robust, here's info on the three machines. Notice the failing one isn't the oldest OS.
I can't find a difference in these 'predictor' variables. Again, I don't care about this particular machine --but more about its value improving the robustness of
remotes::install_github()
(eg, finding an environmental setting/variable value that determine the best download method).Windows machine 1 (which fails):
utils::download.file(source_url, destfile="aa.zip")
see error message aboveR.version
3.4.4 PatchedgetOption("download.file.method")
: "wininet"capabilities(c("libcurl", "http/ftp"))
: TRUE TRUEutils::download.file(source_url, destfile="aa.zip", method="libcurl")
: worksdevtools::install_github("yihui/testit")
: worksrequest <- httr::GET(source_url); writeBin(httr::content(request, "raw"), con="aa.zip")
: works (ie, my interpretation of devtool's internals)Windows machine 2 (which works):
utils::download.file(source_url, destfile="aa.zip")
worksR.version
3.4.4 PatchedgetOption("download.file.method")
: "wininet"capabilities(c("libcurl", "http/ftp"))
: TRUE TRUEutils::download.file(source_url, destfile="aa.zip", method="libcurl")
: worksdevtools::install_github("yihui/testit")
: worksrequest <- httr::GET(source_url); writeBin(httr::content(request, "raw"), con="aa.zip")
: worksWindows machine 3 (which works):
utils::download.file(source_url, destfile="aa.zip")
worksR.version
3.4.4 PatchedgetOption("download.file.method")
: "wininet"capabilities(c("libcurl", "http/ftp"))
: TRUE TRUEutils::download.file(source_url, destfile="aa.zip", method="libcurl")
: worksdevtools::install_github("yihui/testit")
: worksrequest <- httr::GET(source_url); writeBin(httr::content(request, "raw"), con="aa.zip")
: worksFollow question:
Ideas why
devtools::install_github()
doesn't have this problem? Is it becausehttr::GET()
is used instead? (Notice I included that as the 8th characteristic in the list above.)I see a lot of Google hits for ""InternetOpenUrl failed: 'A connection with the server could not be established'". Is this why you guys avoided
utils::download.file()
indevtools::install_github()
? I understand the appeal of avoiding additional package dependencies (eg httr) and relying on required packages (like utils).gaborcsardi commentedon Sep 22, 2018
httr uses curl, which uses its own libcurl.
I am pretty sure that this is the GH TLS issue. If you still have that problematic machine, can you please try to install TLS 1.2 support? Note that the next release of devtools will use remotes, so the devtools workaround will soon stop working.
wibeasley commentedon Sep 23, 2018
This guide recommended enabling TLS 1.2 in IE 10. That worked. But it's not very satisfying because when I then unchecked the box, it still worked. I'm guessing that checking the box the first time set something in the registry that helped
utils::download.file()
?I didn't see anything to install in that link above that applies to Windows 8. I think part of the complexity was that the machine can't be upgraded to Windows 8.1.
This isn't my main computer, so again, I don't really care for my sake. But if there's something else I can run or do that might help you, please tell me. otherwise, I think this issue can be closed.
gaborcsardi commentedon Sep 23, 2018
Thanks! I don't think we can do much more here.
ShaowenJ commentedon Nov 27, 2018
Hi guys, if I can use utils::download.file(,method="libcurl") to download the file like wibeasley did, how can I install it?
36 remaining items