Impact of warning on absolute paths for include_graphics()

[davidski]

By filing an issue to this repo, I promise that

• I have fully read the issue guide at https://yihui.org/issue/.
• I have provided the necessary information about my issue.
  • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
  • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('knitr'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('yihui/knitr').
  • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
• I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

Following the recent change to include_graphics() I'm regrettably the squeaky wheel for whom #2063 (review) is very inconvenient/annoying. 😉

My team's image work flow involves a custom function that takes a ggplot image, does some external processing and mutliple file creation, returning an absolute file path to the notebook-ready image to be included in the Rmd file. We then pipe this into include_graphics() for inline display and knitting purposes. With this change, we get a warning on every image we include, and our notebooks have dozens, if not hundreds of images. It's rather maddening.

I suspect the motivation is to encourage relative paths for direct use of include_graphics(), helping to ensure portability of code. This doesn't take into account users that are programmatically creating paths at run/knit-time, such as the use of here() which take care of the relative directory issue already.

If this change needs to be kept in, can it please be configurable via an options setting? The current knitr release is very frustrating for our flow. Thanks for the dialog!

[yihui]

Sorry about the trouble! As I said in #2063 (review), I'm willing to revert this change, and I'm also happy to provide an option to suppress the warning.

This doesn't take into account users that are programmatically creating paths at run/knit-time, such as the use of here() which take care of the relative directory issue already.

I recommend against using functions like here::here() that return absolute paths inside include_graphics(). Could you let me know a little more about your file structure? I'm curious about why you can't use relative paths. BTW, xfun::from_root() might help---it's similar to here::here() but returns relative paths.

[davidski]

Appreciate the conversation!

Our workflow has a common directory figs at the root of each project. figs contains a unique subdir for each notebook in a project. While we typically have a common notebooks subdir for our work, there are other scripts and notebooks outside of those locations that need to be able to construct a path to the project's figs tree without knowing their current location. We solve that via here::here(), which gives us an absolute path for our custom ggsave process (does a bit more than that, but those details are probably not relevant). That (absolute) path then gets returned to the code block as an invisible, which we pass to include_graphics() for display in-line.

Taking the absolute path and back-converting to a relative path was one option I've been thinking about, but that requires touching a lot of code and, in the case of xfun, taking another direct dependency. Just an option to disable the warnings for when users are handling the portability of documents via their code (taking care of the path.expand() that was added) would be great -- if it doesn't introduce too much code to maintain within knitr.

[kendavidn]

Have just run into this issue as well!

So one additional vote in favor of silencing the warning.

The xfun::from_root() function seems quite good (thank you for writing it!), but moving everyone over to this from here::here() will be a heavy lift.

[yihui]

For sure I'll silence the warning by default in the next version. I'm currently busy with another thing, and will come back to this issue as soon as possible.

I really appreciate your feedback!

[yihui]

I've changed the behavior of this function. Now it will try to automatically convert absolute paths to relative paths. The warning will be issued only if any absolute path cannot be converted. You may test the development version via

remotes::install_github('yihui/knitr')

I guess that should solve the problem in most cases, and I'm also open to silencing the warning by default. You can set options(knitr.graphics.rel_path = FALSE) to avoid the warning, too.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.