Suppress evaluation of knitr chunk options in custom language engine

Publishing Your Results
, ,
6

Just about this part, are you looking to set the engine.opts by default for the tar_target engine ?
Not sure but ICYMI you can set defaults to engine.opts per engine. It is hidden in example in 15.4 Execute Shell scripts | R Markdown Cookbook and shown in the doc

Something like this should work to set default option to the engine

knitr::opts_chunk$set(engine.opts = list(
  tar_target = list(...)
)

But I guess you can set default at the engine level so this would be for the user only.

About your proposal, a mechanism like that to filter out option would work in knitr maybe, but it would require to handle namespace to avoid conflict.

Generic thoughts about this specific engine: it seems we could generalize what you want to do by see templated chunk

```{function_name, label, optional_aguments}
main argument
```

epoxy offers a glue() engine that seems to follow this pattern

```{glue, .transformer = epoxy_style_bold()}
All cars stopped between {min(cars$dist)} and {max(cars$dist)} feet
from a starting speed of {min(cars$speed)}---{max(cars$speed)}
```

I am just seing this and this makes me thing of this pattern more. Maybe there a generic way to improve :thinking:

However, often the question for this usage is the same: is this easier to write with a specific engine compare to using the function in an R chunk ?

```{tar_target analysis, engine.opts = list(pattern = "map(data)", error = "continue")}
run_analysis(data)
```

or

```{r}
tar_target(
  name = analysis,
  command = run_analysis(data),
  pattern = map(data),
  error = "continue"
)
```

I understand the added value is that the tar_target engine would modify the way the code is evaluated. But you could also use this engine specific engine to change the evaluation of the code (compare to default R engine) without requiring change of the code user already know (prevent setting arguments in chunk option with all the limitation we mentioned)

```{targets}
tar_target(
  name = analysis,
  command = run_analysis(data),
  pattern = map(data),
  error = "continue"
)
```

Is that too simple ?

Other possible interface

```{r, targets = TRUE}
tar_target(
  name = analysis,
  command = run_analysis(data),
  pattern = map(data),
  error = "continue"
)
```

This would be a way to activate some hooks on the R engine only for chunk used for targets. It is not like a custom engine but could also work maybe - just another interface.

You may have look into that also but it was hard to follow in the Github discussion the different design phase you had.

Again I don't really use targets, only saw examples and demo so I am not sure what the aim is to be able to define the pipeline in a Rmd document. What I understand:

  • Use Rmd instead of _targets.R to write the pipeline.
    • Advantage: use prose instead of comments in files ? Interleave target definition with other type of code ?
  • Do not evaluate the chunk as R code but write into the R file _targets.R from the code chunk and do nothing else in knitr
  • Print back in the resulting document another piece of code that the original one or just log of what has been done (not sure to see what the final document look like)

Is that right ?

1 Like