[R-pkg-devel] Suppressing long-running vignette code in CRAN submission

[John Fox]

Dear Shu Fai,

This approach is certainly relevant, and I think it is slightly better 
than using R.rsp. My preference is still to include the original .Rmd 
file along with a note to CRAN about the long-running vignette.

Thank you,
  John


On 2023-10-17 9:25 p.m., Shu Fai Cheung wrote:
> Caution: External email.
> 
> 
> Please pardon me if I suggest something unrelated below. Many experts
> have made suggestions that I would also like to consider because I
> also have a similar issue with some packages.
> 
> This is an approach I found, for Rmarkdown vignettes:
> 
> https://www.kloppenborg.ca/2021/06/long-running-vignettes/
> 
> This is similar to some of the suggestions. The vignette is rendered
> locally. It uses the trick that, If we render the vignette by calling
> knitr::knit() directly, the extension of the source file does not
> matter. The output, although with the extension ".Rmd", actually
> contains the results of the code, in chunks starting with "```r", not
> "```{r}".
> 
> When this pre-buiult .Rmd file is built again, it will just convert
> the file to an HTML file, with no need to rerun the code.
> 
> The method uses an extension for the source Rmd file (".orig" in the
> post) to make sure the "real" source files are ignored when building
> the vignettes.
> 
> Perhaps this is also a feasible solution for long running vignettes?
> 
> Regards,
> Shu Fai
> 
> On Wed, Oct 18, 2023 at 6:51 AM John Fox <jfox using mcmaster.ca> wrote:
>>
>> Dear John,
>>
>> Unless I'm mistaken, the *installation* time of the package isn't really
>> at issue. If a user installs a package from a tarball provided by CRAN,
>> the vignettes aren't normally rebuilt.
>>
>> Best,
>>    John
>>
>> On 2023-10-17 6:30 p.m., John Harrold wrote:
>>> Caution: External email.
>>>
>>>
>>> I ask myself the question: Who is the vignette for?  It does server two
>>> purposes. One is testing but primarily it's for the users to learn how to
>>> use a package. I think the testing is secondary, and if it slows down
>>> installation or general usability I'd sacrifice the testing. If it's that
>>> important, then the tests can be added explicitly in tests/.
>>>
>>> On Tue, Oct 17, 2023 at 3:04 PM Dirk Eddelbuettel <edd using debian.org> wrote:
>>>
>>>>
>>>> On 18 October 2023 at 08:51, Simon Urbanek wrote:
>>>> | John,
>>>> |
>>>> | the short answer is it won't work (it defeats the purpose of vignettes).
>>>>
>>>> Not exactly. Everything is under our (i.e. package author) control, and
>>>> when
>>>> we want to replace 'computed' values with cached values we can.
>>>>
>>>> All this is somewhat of a charade. "Of course" we want vignettes to run
>>>> tests. But then we don't want to fall over random missing .sty files or
>>>> fonts
>>>> (macOS machines have been less forgiving than others), not to mention
>>>> compile
>>>> time.
>>>>
>>>> So for simplicity I often pre-make pdf vignettes that get included in other
>>>> latex code as source. Works great, never fails, CRAN never complained --
>>>> which is somewhat contrary to your statement.
>>>>
>>>> It is effectively the same with tests. We all want maximum test surfaces.
>>>> But
>>>> when tests fail, or when they run too long, or [insert many other reasons
>>>> here] so many packages run tests conditionally.  Such is life.
>>>>
>>>> Dirk
>>>>
>>>>
>>>> | However, this sounds like a purely hypothetical question - CRAN policies
>>>> allow long-running vignettes if they declared.
>>>> |
>>>> | Cheers,
>>>> | Simon
>>>> |
>>>> |
>>>> | > On 18/10/2023, at 3:02 AM, John Fox <jfox using mcmaster.ca> wrote:
>>>> | >
>>>> | > Hello Dirk,
>>>> | >
>>>> | > Thank you (and Kevin and John) for addressing my questions.
>>>> | >
>>>> | > No one directly answered my first question, however, which was whether
>>>> the approach that I suggested would work. I guess that the implication is
>>>> that it won't, but it would be nice to confirm that before I try something
>>>> else, specifically using R.rsp.
>>>> | >
>>>> | > Best,
>>>> | > John
>>>> | >
>>>> | > On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
>>>> | >> Caution: External email.
>>>> | >> On 16 October 2023 at 10:42, Kevin R Coombes wrote:
>>>> | >> | Produce a PDF file yourself, then use the "as.is" feature of the
>>>> R.rsp
>>>> | >> | package.
>>>> | >> For completeness, that approach also works directly with Sweave.
>>>> Described in
>>>> | >> a blog post by Mark van der Loo in 2019, and used in a number of
>>>> packages
>>>> | >> including a few of mine.
>>>> | >> That said, I also used the approach described by John Harrold and
>>>> cached
>>>> | >> results myself.
>>>> | >> Dirk
>>>> | >> --
>>>> | >> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>>>> | >> ______________________________________________
>>>> | >> R-package-devel using r-project.org mailing list
>>>> | >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>> | >
>>>> | > ______________________________________________
>>>> | > R-package-devel using r-project.org mailing list
>>>> | > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>> | >
>>>> |
>>>> | ______________________________________________
>>>> | R-package-devel using r-project.org mailing list
>>>> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>> --
>>>> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>>>>
>>>> ______________________________________________
>>>> R-package-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>
>>>           [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel