Strange error with callr

[jl5000]

Hi Will, in reference to my Twitter message, I've been using drake for a while now on my work computer and thought I would try converting an existing drake workflow to targets. Unfortunately, I was getting a persistent error so I tried out the minimal example, but still getting the same error. I get this running any command, such as tar_manifest():

Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object 'C:/Users/me/AppData/Local/Temp/Rtmp6hlxhU/file6d03d2a346c.dll':
LoadLibrary failure: This program is blocked by group policy. For more information, contact your system administrator.
Calls: -> dyn.load -> inDL
Execution halted
Error: callr subprocess failed: could not start R, exited with non-zero status, has crashed or was killed
Visit https://books.ropensci.org/targets/debugging.html for debugging advice.

We do have our laptops locked down, but we are able to install and use packages. Do you have any idea what might be causing this problem because this could have a big hit on our reproducibility.

[wlandau]

Could be an instance of https://stackoverflow.com/questions/52150491/error-in-indlx-as-logicallocal-as-logicalnow-unable-to-load-share or https://community.rstudio.com/t/problems-with-r-4-0-0-windows-error-package-or-namespace-load-failed-for-stats-in-indl-x-as-logical-local-as-logical-now/62958/8? To confirm, maybe you could run tar_manifest(callr_function = NULL) and look at the traceback. What about another callr call like callr::r(function() library(tidyselect))?

[jl5000]

Wow, tar_manifest(callr_function = NULL) seemed to work. I admit I saw those SO links previously, but couldn't really tell if they were relevant. Your final suggestion failed. I'm not sure what this means.

[wlandau]

I think it means the issue has something to do with how your Windows installation is launching external processes. We already found out it has something to do with infrastructure and not targets itself. Let's keep peeling back layers. What if you invoke processx directly? Depending on the result, I recommend posting an issue to either callr or processx and following up there.

library(processx)
bin <- file.path(R.home(), "bin", "Rscript")
writeLines("library(tidyverse)", "script.R")
px <- process$new(bin, "script.R", stdout = "out.txt", stderr="err.txt")
px$wait()
writeLines(readLines("out.txt"))
writeLines(readLines("err.txt"))
#> ── Attaching packages ─────────────────────────────────────── tidyverse 1.3.0 ──
#> ✓ ggplot2 3.3.3     ✓ purrr   0.3.4
#> ✓ tibble  3.1.0     ✓ dplyr   1.0.5
#> ✓ tidyr   1.1.3     ✓ stringr 1.4.0
#> ✓ readr   1.4.0     ✓ forcats 0.5.1
#> ── Conflicts ────────────────────────────────────────── tidyverse_conflicts() ──
#> x dplyr::filter() masks stats::filter()
#> x dplyr::lag()    masks stats::lag()

^{Created on 2021-03-08 by the reprex package (v1.0.0)}

[jl5000]

This one seemed to work. So I guess the issue is with callr?

[wlandau]

Seems like the next place to check.

[jl5000]

Thanks very much for your help.