[help] RMarkwodn report as tar_render() with dynamic tabs #138
-
Help
DescriptionHi! However, when I integrate the report into the targets-pipeline, I run into problems with the working directories. I have a structure, where the R-project folder (thus the beginning of here()) containts multiple sub-projects, each with a targets-pipeline in it. In yet another sub(sub)folder is the report. To better understand what happens, I turned keep_md: TRUE. I can see, that the plot-files are created in the directory of the report.rmd, however they are then searched for in the main here()-directory. What works is storing the report in the main r-project-folder, where here() starts. This is not a solution I can really work with, so I am looking for a way to specify where the created plots for the tabs should be searched for. Or at least, that these documents are also created in the main here()-folder, since they are usually deleted after the report is created. My guess is that this issue has something to do with tar_render()'s charactersitic "4. Forces the report to run in the user's current working directory instead of the working directory of the report" (from the help-file). Unfortunately, I have not idea how to change this behaviour. Can anyone help? Since the folder-structure is difficult to describe I tried to create a reprex, let me know if it needs improvement. It's the first reprex I did in this way. https://github.com/tkuentzler/reprex_tarchetype_rmrarkdown Thank you for any help in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
I ran your reprex with Have you tried #134 (reply in thread) in the full project? This use case seems related to #134. |
Beta Was this translation helpful? Give feedback.
I ran your reprex with
reprex_here/reprex_subproject
as the working directory, and unfortunately I could not reproduce the issue you describe. The outputreport.html
successfully loads the plots (see below).Have you tried #134 (reply in thread) in the full project? This use case seems related to #134.