Safely allow tar_quarto() etc. to run the report from a custom working directory

[wlandau]

Many users have hit problems over the years while running tar_render() reports that live in subdirectories. targets requires each target to run from the root directory of the project for safety reasons, but this interferes with knitr and Quarto because of their own path management conventions. I was initially reluctant to expose knit_root_dir, execute_dir (even now I would probably use with::local_dir()). But we could allow the change in working directory if there are extra guardrails to make sure the user supplies a store argument to tar_read() and tar_load() in the report. The static code analysis could check this:

tarchetypes/R/utils_knitr.R

Lines 87 to 109 in 8507cfd

	walk_load <- function(expr, counter) {
	expr <- match.call(targets::tar_load, as.call(expr))
	if (is.null(expr$names)) {
	targets::tar_warn_validate(
	"Found empty tar_load() call in a knitr / R Markdown ",
	"code chunk. Dependencies cannot be detected statically, ",
	"so they will be ignored."
	)
	}
	walk_target_name(expr$names, counter)
	}
	walk_read <- function(expr, counter) {
	expr <- match.call(targets::tar_read, as.call(expr))
	if (is.null(expr$name)) {
	targets::tar_warn_validate(
	"Found empty tar_read() call in a knitr / R Markdown ",
	"code chunk. Dependencies cannot be detected statically, ",
	"so they will be ignored."
	)
	}
	walk_target_name(expr$name, counter)
	}

[wlandau]

On second thought, I don't think we will need extra code analysis checks. The behavior will be documented in the working_directory argument, and the error message about not finding the data store will speak for itself.

[wlandau]

The reason for omitting this check is that users could have a _targets.yaml which tar_config_get() would understand, which could automatically set good defaults for tar_read() and tar_load() in reports.