Fix up knitr paths relative to the output directory

[hadley]

For some unknown reason, knitr_print() methods sometimes produces paths are relative to the input directory, rather than to the output directory. This PR re-parents those to paths to be relative to the output directory making them work again.

Fixes #2334. Fixes #2341.

@thomasp85 would you mind checking that this fixes the gganimate site?

(To do: add a test so I don't accidentally break this again in the future)

[thomasp85]

LGTM - this fixes the gganimate website and, I assume, other sites relying on gganimate

[cderv]

For some unknown reason, knitr_print() methods sometimes produces paths are relative to the input directory, rather than to the output directory.

About this, my understanding is the following

• magick and gganimate both have knit_print methods that write their produced file in knitr::fig_path(). In rmarkdown context, this will be a path inside the output directory.
• knitr::include_graphics() is used to include that path in the document, though it will be used with absolute path (as pkgdown use absolute path to call render() IIUC)
• knitr::include_graphics() used on external resources will often be used on local resources relative to input.

This could lead to both input and output relative resources.

knitr::include_graphics() tries to handle the absolute to relative conversion, but it does not handle this output relative resources. This is to be fixed so that what magic and gganimate are doing works ok.

Clearly something to fix in knitr and/or rmarkdown

[cderv]

This may also be a breakage in rmarkdown 2.26. Absolute paths in HTML using output directory should have been made relative by rmarkdown::html_document_base post processor, and pkgdown should not need to deal with absolute path;

It should be fix soon and we'll do a patch release.

[hadley]

@cderv I think this problem is separate (if related), because it's a long standing issue.

[cderv]

Oh ok. From my quick tries of the examples of the two issues, I was really under the impression that the path handling absolute to relative to output-dir should have been handled by markdown post-processing. I'll recheck no matter the state of this PR to be sure there is nothing hidden in R Markdown or knitr

[hadley]

Awesome, thanks @cderv!

[hadley]

@cderv the windows failure is interesting — knitr certainly shouldn't be generating a path like ../../../../../../../../../../../C:/Users/runneradmin/AppData/Local/Temp/RtmpaaQWna/working_dir/RtmpusN7Up/file1434ec52ec2/articles/kitten_files/figure-html/magick-1.png (assuming that's not because I'm mangling the path in pkgdown).

[cderv]

So I looked closer into all the examples in pkgdown issue and the problem we have in knitr.

Considering that the 2.26 regression is fixed (rstudio/rmarkdown#2554), we are left with issue of include_graphics() default path processing. This is now explained in

• default relative path processing in include_graphics() can create broken path yihui/knitr#2171

I do believe that setting rel_path = FALSE for include_graphics() should solve your issue here. It can be done using knitr.graphics.rel_path = FALSE options to apply on all call to the function.

This relative path processing is unaware of the full rendering context enough to do the right work. It will only make path relative to the input directory, and so do not account for usage of include_graphics() with knitr::fig_path(), which both gganimate and magick knit_print() method are using.

pkgdown makes this issue surface because it uses absolute path for input and output in its call to rmarkdown::render()

Also when output_dir is not a subfolder of the input directory, this will lead to relative path with lots of ../. And this is what happens in CI

• By default on Windows runner, the temp directory will be in another drive (c:/) than the working directory (d:).
  • This different drives can be problem sometimes. I know that in some project I already needed to change R temp to use runner one to have same drive. I reported it a while back (Set R temp directory to be in Runner temp directory actions#217).
• So here, your pkgdown site is in your test folder, but pkgdown output dir is in a temp directory in another drive.
• The relative path processing creates this long relative path (valid on windows I think) from output temp dir to the assets in tests folder.
• I don't know if knitr should detect weird path like this that are on different drives. It is a combination of input and output dir being set to very different location. It needs to be better handling path in output directory though, and this would probably avoid this kind of path problem.

All comes to include_graphics(rel_path = FALSE). I believe if this is set

• You can keep doing the fixup to change absolute path to relative from the input directory
• All absolute relative to the output directory will be fix up by rmarkdown::render() with html_document_base() - except in 2.26 where it is broken in some specific case but will be fixed by Fix regression w/ image path processing from absolute to relative rstudio/rmarkdown#2554

I'll try a forked version of this PR to verify my understanding of this.

[cderv]

FWIW my test in #2508 is successful after a few tries.

Two things are needed to solve all issues

• Setting the option for knitr rel_path
• Using dev rmarkdown to have the regression fix

Remaining CI failure here seems unrelated to rmarkdown / knitr path handling