Open csgillespie opened 5 years ago
Wow, interesting. I wonder if this should also be reported as a bug in R. For future records, what version of R are you observing this on?
There's a couple of screenshots as well.
R> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so
locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C LC_TIME=en_GB.UTF-8
[4] LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] roxygen2_6.1.1 prettycode_1.0.2 colorout_1.2-0
loaded via a namespace (and not attached):
[1] compiler_3.5.1 R6_2.3.0 magrittr_1.5 tools_3.5.1 withr_2.1.2
[6] rstudioapi_0.9.0 Rcpp_1.0.0 crayon_1.3.4 xml2_1.2.0 stringi_1.2.4
[11] stringr_1.3.1 packrat_0.5.0 commonmark_1.7 fortunes_1.5-4
And just to be 100% on the same page, will running that devtools::document(...)
from the RStudio Console also fail?
devtools::document()
works in both the Rstudio console and RStudio terminal. Likewise, a standard R CMD build XXX doesn't work.
I'd like to confirm this in order to rule out that it's a devtools bug. As a test trying to figure out what's going on, I've added the following to my ~/.Rprofile
:
system2("echo", args = "[system] .Rprofile ...")
.libPaths(c(tempfile(), .libPaths())
system2("echo", args = c("[system] .libPaths: ", .libPaths()))
system2("echo", args = "[system] .Rprofile ... done")
to confirm that R CMD build
does indeed source .Rprofile
:
$ R CMD build listenv
[system] .Rprofile ...
[system] .libPaths: /home/hb/R/x86_64-pc-linux-gnu-library/3.5 /usr/local/lib/R/site-library /usr/lib/R/site-library /usr/lib/R/library
[system] .Rprofile ... done
* checking for file ‘listenv/DESCRIPTION’ ... OK
* preparing ‘listenv’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘listenv_0.7.0-9000.tar.gz’
So, it's not that ~/.Rprofile
is skipped by R CMD build
itself at the top level. However, it could still be that there are some internal system calls that R CMD build
performs that runs with --vanilla
or similar.
One further step forward.
# The first dir is the one with knitr and loaded in .Rprofile
> .libPaths()
[1] "/data/ncsg3/Rpackages" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
> tools:::.build_packages("benchmarkme/")
* checking for file ‘benchmarkme/DESCRIPTION’ ... OK
* preparing ‘benchmarkme’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
Error in loadVignetteBuilder(vigns$pkgdir) :
vignette builder 'knitr' not found
Calls: <Anonymous> -> loadVignetteBuilder
Execution halted
Error in do_exit(1L) : .build_packages() exit status 1
See https://github.com/wch/r-source/blob/47b75782bb459cd481e6635852ec5c234b4f530e/src/library/tools/R/build.R#L22 for function reference
In my
.Rprofile
I've recently added.libPaths("/path/")
Interestingly, this usually works, but occasionally it doesn't. For example,
path/
Likewise, a standard
R CMD build XXX
doesn't work.Proposal: have
check()
detect and warn as necessary. Happy to attempt a PR.The reason I have it in my
.Rprofile
was due tolittler
ignoring.Renviron
files (https://github.com/eddelbuettel/littler/issues/64)