[R-pkg-devel] maintainer built vignette

Ian Carroll icarroll at sesync.org
Fri Apr 7 06:15:51 CEST 2017

With `BuildVignettes: no` in my DESCRIPTION and `^vignettes` in my .Rbuildignore, I can squeak through a normal build (no `r_build_args` or `r_check_args`) on travis with just this note:

    * checking for old-style vignette sources ... NOTE
    Vignette sources only in ‘inst/doc’:
    A ‘vignettes’ directory is required as from R 3.1.0
    and these will not be indexed nor checked

I’ll take a NOTE over an ERROR, so I’ll try to submit like this with an explanation. It seems to me like `BuildVignettes: no` should also disable re-building them under R CMD check, but I think R CMD check --as-cran clobbers it.

-----Original Message-----
From: Dirk Eddelbuettel <dirk.eddelbuettel at gmail.com> on behalf of Dirk Eddelbuettel <edd at debian.org>
Date: Thursday, April 6, 2017 at 9:23 PM
To: Ian Carroll <icarroll at sesync.org>
Cc: "r-package-devel at r-project.org" <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] maintainer built vignette

    On 6 April 2017 at 20:17, Ian Carroll wrote:
    | How do I package an rmarkdown vignette that cannot be built on win-builder? The vignette in question demonstrates interaction with a SLURM cluster, which is not available to win-builder or travis. In my `.travis.yml` I can include `r_build_args: "--no-build-vignettes"` and `r_check_args: "--no-vignettes"` to skip the build and re-build steps respectively. I don’t know how to do that with win-builder, so I cannot pass the incoming pretest on package submission. The extra steps make me feel like I’m doing something wrong regardless.
    | So, what’s the appropriate way to include vignettes that should not be hammered with attempts to build at every turn? Some old advice seemed to suggest going straight to inst/docs, but newer rules are that inclusion in vignettes/ is mandatory.
    I think if you adjust .Rbuildignore to NOT include the source but just the
    pdf then you will have documentation present -- without the risk of 'cannot
    be computed here' on some platforms.
    http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

More information about the R-package-devel mailing list