[R-pkg-devel] Avoid reprocessing Rmd vignette
tkeitt at utexas.edu
Tue Mar 20 03:54:43 CET 2018
On Mon, Mar 19, 2018 at 2:18 AM, Iñaki Úcar <i.ucar86 at gmail.com> wrote:
> 2018-03-19 3:57 GMT+01:00 Tim Keitt <tkeitt at utexas.edu>:
> > http://www.keittlab.org/
> > On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel <edd at debian.org>
> >> Tim,
> >> On 18 March 2018 at 18:58, Tim Keitt wrote:
> >> | I have an Rmd vignette that runs some benchmarks. It takes long enough
> >> (20+
> >> | minutes) that eg TravisCI will choke. I've not tried submitting to
> >> | What is the best practice for handling this situation? Do I generate
> >> | HTML/PDF output locally and try to make them static? The vignette
> >> | is knitr. I know about the R.rsp package but I do not know if it
> >> | Rmd files.
> >> Tests are tickled from a runner script such as either one of
> >> tests/doRUnit.R
> >> tests/testthat.R
> >> so you have an entry point to control for environment variables.
> >> Travis clearly documents what theirs are -- so you could just turn it
> >> --
> >> and I have opted (years ago) for a more endogeneous scheme of
> >> tests on CRAN based on version numbers (as I suppress tests when version
> >> numbers are "release-style" form 'a.b.c', but then run the tests when
> >> version number is "dev-style" ie a.b.c.d).
> > That's a great idea, however my problem is with building a vignette, not
> > running tests, unless they are linked in some way I'm not understanding.
> One of my packages on CRAN contains a vignette with a benchmark. You
> can check what I do here (search for "microbenchmark"):
> Basically, those chunks that use microbenchmark are marked as
> "eval=FALSE", and the resulting figures are static images. I run those
> manually and update the images from time to time if something relevant
> changed. Apart from saving compilation time, this way I don't need to
> include microbenchmark as a dependency.
Thanks. That is helpful.
I thought I had tried this method with a recent package and still ran into
problems with CRAN. The issue seemed to be that the R code is extracted
from the knitted output and run a second time where the chunk options no
longer apply. At least I thought that was what was happening. Glad to hear
this can work if so.
(Incidentally, I don't use microbenchmark for this one as I need to
generate random data per trial and don't want to include that in the
timing. A few lines of C++ does the trick.)
> > THK
> >> You can alternatively check for CRAN via an env.var; I forget what it is
> >> called and cannot grep for it as my scheme does not need it. WRE may
> >> you
> >> what it is.
> >> Hth, Dirk
> >> --
> >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
[[alternative HTML version deleted]]
More information about the R-package-devel