R CMD build does not create purl()'ed R files when _R_CHECK_TIMINGS_ is set to 0

[dtenenba]

Not sure if this is a bug or not, but maybe you can tell me.

When _R_CHECK_TIMINGS_ is set to 0, R CMD build produces a tarball that does NOT include the purl()ed vignette R file:

biocbuild@zin1:~/bbs-3.4-bioc/meat$ _R_CHECK_TIMINGS_=0 R CMD build RGalaxy
* checking for file ‘RGalaxy/DESCRIPTION’ ... OK
* preparing ‘RGalaxy’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building ‘RGalaxy_1.17.2.tar.gz’

biocbuild@zin1:~/bbs-3.4-bioc/meat$ tar ztf RGalaxy_1.17.2.tar.gz |grep inst/doc
RGalaxy/inst/doc/
RGalaxy/inst/doc/RGalaxy-vignette.Rmd
RGalaxy/inst/doc/RGalaxy-vignette.html

When the variable is NOT set, the R file is present:

biocbuild@zin1:~/bbs-3.4-bioc/meat$ R CMD build RGalaxy
* checking for file ‘RGalaxy/DESCRIPTION’ ... OK
* preparing ‘RGalaxy’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building ‘RGalaxy_1.17.2.tar.gz’

biocbuild@zin1:~/bbs-3.4-bioc/meat$ tar ztf RGalaxy_1.17.2.tar.gz |grep inst/doc
RGalaxy/inst/doc/
RGalaxy/inst/doc/RGalaxy-vignette.R
RGalaxy/inst/doc/RGalaxy-vignette.Rmd
RGalaxy/inst/doc/RGalaxy-vignette.html

I am not sure what _R_CHECK_TIMINGS_ is supposed to do, but I assume from the name that it has to do with R CMD check, not R CMD build, so I am surprised that R CMD build is affected by this.

Can you shed some light on this?
Thanks,
Dan

@mtmorgan
@hpages
@aoles

biocbuild@zin1:~/bbs-3.4-bioc/meat$ R -q --vanilla
> library(knitr);sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] knitr_1.13

loaded via a namespace (and not attached):
[1] tools_3.3.0

[aoles]

@dtenenba, setting _R_CHECK_TIMINGS_ tricks knitr into thinking that R CMD check is run, which in turn disables some feature, including purling, see
https://github.com/yihui/knitr/tree/master/R/utils.R#L719-L723
and
https://github.com/yihui/knitr/tree/master/R/utils-vignettes.R#L45-L52

@yihui, not sure but maybe there is a more robust way of determining whether R CMD check is run?

[yihui]

@aoles You are right. I don't know a "robust" way of determining R CMD check (I don't think such a way exists), and I don't know why _R_CHECK_TIMINGS_ has to be set for R CMD build.

[dtenenba]

The bioconductor build system, which runs both R CMD build and R CMD check sets that variable.
It would be too much work to set it for the build phase and then unset it for the check phase.
But apparently according to https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Check-timing , if I read it right, specifying the --timings switch to R CMD check (which our build system already does) makes it unnecessary to set _R_CHECK_TIMINGS_, so I have stopped setting it and we'll see if that clears things up in the next build tonight. So we are attempting to work around this but it still seems like a bug.

There must be some other way to determine if R CMD check is being run?
On Unix at least, you could see if the $R_HOME/bin/check script is a parent of the current process.
You could also maybe intuit it by seeing if R_DEFAULT_PACKAGES is unset and LC_COLLATE is set to C, as the aforementioned script invokes R with those settings. But on Windows there is no check script and I don't know if it sets variables the same.

You could write a package which has an example or unit test that outputs some information to a file (such as all environment variables and the command line arguments that R was invoked with), and then run R CMD check on that package, that might help you figure it out. Or ask on r-devel.

[yihui]

I won't ask r-devel. It is simply a hack, and I don't want to get CRAN maintainers' attention. If there is no particular reason for you to set _R_CHECK_TIMINGS_, I hope you could just use --timings instead.

[dtenenba]

I'll see how our builds go with that change and let you know. Thanks.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.