Creating plan in Rmd file - knit() same chunk names

[rkrug]

I am creating a drake plan in an R notebook for documentation purposes. The planknits at the end a. Rmd file:

plan %<>% bind_rows(
  drake::drake_plan(
    knit(
      knitr_in( "TESTRmd" ), 
      file_out( "TEST.html" ), 
      quiet = TRUE
    )
  )
)

at the same time, I have a setup chunk in the Rmd which creates plan as well as in the file TEST.Rmd This results in the file not be parsed. I know this is an unusual use (creating the plan in an R notebook).

[wlandau]

Sorry, I am having trouble understanding the problem. Is make() not working correctly, or does drake_plan() complain that it cannot find TEST.Rmd? Are you creating TEST.Rmd before creating the drake_plan() that uses it?

[wlandau]

Ah, just re-read the title: I think TEST.Rmd cannot have conflicting chunk names with your R notebook. I encountered similar problems with drake vignettes that run examples with a report.Rmd.

[wlandau]

Closing because I assume this problem is related to duplicate chunk names (chunk names need to be unique among all the reports). Please correct me if I am wrong, and I will reopen.

[rkrug]

You are right - that is causing the problem, but it is not obv=ious that it is like that. I would suggest to add an informative warning int the vignette which deals with knitting. But this question goes along the lines of isolation: Wherever I run `make()`, the result should be the same. In other words: If I run `make()` at an R prompt, Commandline (via littler) , from an R script, or from RStudio, the results should be the same - that is the principle of reproducibility as I understand it. For this to work, the approach to compiling the targets probably needs to be tweaked. The best and safest option probably would be to do the compilation in a new `R -- vanilla session`, but I don’t know if this would be feasible (and possible). But at least in the case of knitting, the `make()` process should not fail. Rainer

…

On 19 Mar 2018, at 15:06, Will Landau ***@***.***> wrote: Closing because I assume this problem is related to duplicate chunk names (chunk names need to be unique among all the reports). Please correct me if I am wrong, and I will reopen. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdvBBVDfmc0cS9uQvl8Nmtjs42Ohlgpks5tf7tLgaJpZM4SwGk3>.

-- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) University of Zürich Cell: +41 (0)78 630 66 57 email: Rainer@krugs.de Skype: RMkrug PGP: 0x0F52F982

[wlandau]

I do agree, but drake cannot fix the issue of nested colliding reports because it has no control over the internals of knitr.

[rkrug]

No - it can't. But shouldn't creating a target, be independent from where it is build?

This leads to the question already partly raised: how dependent is the target from the environment it is called in? How do loaded packages affect the result? Can local variables change the result?

> plan <- drake_plan(test = x + 1)
> make(plan)
target test
fail test
Error: Target `test`` failed. Call `diagnose(test)` for details. Error message:
  object 'x' not found
> x <- 1
> make(plan)
target test
>

should always result in the same result, i.e. the error message. I don't know if it is possible anymore without breaking backward compatibility, but I think make() should start its own R --vanilla session and do all compiling of targets in there to avoid the effect of accidental leftover local variables.

The fact that local variables are accessible during make() make life easier in many situations, but they are against the idea that a call to make() should result in reproducible results.

[wlandau]

We can think about a separate session for make(). See #296 (comment).

[rkrug]

Sounds good. Thanks.