[R-pkg-devel] Avoid reprocessing Rmd vignette

Tim Keitt tkeitt at utexas.edu
Tue Mar 20 03:54:43 CET 2018


http://www.keittlab.org/

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>
> wrote:
> >
> >>
> >> 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
> CRAN.
> >> | What is the best practice for handling this situation? Do I generate
> >> | HTML/PDF output locally and try to make them static? The vignette
> builder
> >> | is knitr. I know about the R.rsp package but I do not know if it
> handles
> >> | 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
> off
> >> --
> >> and I have opted (years ago) for a more endogeneous scheme of
> suppressing
> >> 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
> the
> >> 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"):
>
> https://raw.githubusercontent.com/r-simmer/simmer/master/
> vignettes/simmer-07-ctmc.Rmd
>
> 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


>
> Iñaki
>
> >
> > 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
> tell
> >> 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 mailing list