interest in an rmarkdown::render pull request?

[rmflight]

I've just started using remake, and it is awesome. Given that rmarkdown has really nailed going from Rmd to PDF, HTML, etc, I was thinking it would be worth having a type similar to knitr: TRUE, but would be rmarkdown: TRUE that would call rmarkdown::render to generate the target, and keep track of when the input file changes.

Looking at the remake_from_knitr code, I don't think it should be too hard.

Would such a PR be of interest?

[richfitz]

Yes, that would be great, thanks. I am currently fairly ignorant of where the state-of-the-art is in this area, and would appreciate the help

[krlmlr]

Can we work towards a more general rule system that allows custom rules? I'm thinking about something along the following lines:

rules:
  rmd_document:
    call: knit_with_deps(target_name, dep_names)

targets:
  reports/final.html:
    type: rmd_document
    depends:
    - reports/final.Rmd
    - dep1
    - dep2

Please see also #107 for thoughts on standalone execution of documents, and #130 (comment) for knit_with_deps().

[krlmlr]

Or maybe:

rules:
  rmd_document:
    call: knit_with_deps(target_name, dep_names)
    dep_call: figure_out_additional_knitr_deps(dep_names)

targets:
  reports/final.html:
    type: rmd_document
    depends:
    - reports/final.Rmd

[richfitz]

👍 - totally agree

[rmflight]

Yes, custom rules ultimately would be great! Especially because if done right a custom rule could generate anything, including holding the definition of a class defined in a custom package, and if the class changes, the code should be re-run .... (another use case I found yesterday)