But this is more robust thanlocal = TRUE. It works anywhere (e.g. inside a function). It's an absolute environment, andlocal = TRUE is a relative environment, which is subject to your current environment, and could be confusing when it is not called directly in a code chunk but from another function, e.g.,

load_scripts<-function(files) {for (finfiles) source(f,local=TRUE)}load_scripts(c('a.R','b.R'))

Bothlocal = TRUE andFALSE have their usefulness. There isn't an absolutely correct choice, so I didn't strongly emphasize one or another. Perhaps the distinction between the two choices should be explained more clearly in this section. In general, I feelsource("your-script.R", local = knitr::knit_global()) is still the safest choice.

Yeah, if you want to runsource() inside a function and have it impact code outside of the function, you're going to have to do something special. As a general principle, I don't think functions should mutate the global environment in this way, so I do believe thatlocal = TRUE is the correct recommendation here. (And then mentionlocal = knitr::knitr_global() as a special case if youreally want to do that)

But this is now really about advice for writing functions that call source, not about callingsource() in knitr chunks.

We don't recommend ever usingsys.source() as it is designed specifically for internal use by base R.

I haven't heard of this before and am surprised to learn it. Could you point out the source of this claim? The help page?sys.source didn't say it was designed only for internal use by base R. I mentionedsys.source() because it does a much simpler job thansource(), i.e., it basically doeseval(parse()), whereassource() does several other things that are irrelevant to evaluating the code.

I think it's implied by theenvir argument which defaults tobaseenv() — there is no case in which a user would want this. Do you have any evidence to suggest that people are usingsys.source() in the wild?

Usually, knitr will evaluate code in a child of the global environment

Usuallyknitr evaluates code just in the global environment, instead of a child of the global environment.knitr::knit() andrmarkdown::render() haveenvir = parent.frame() by default, which points toglobalenv() if you call them in the global environment.

so any assignments in the source file will be overridden by assignments inearlier chunks

I'm confused: did you mean earlier or later? If you havex <- 1 in the source file, after yousource() it, the assignment will be overridden byx <- 2 in a later chunk. Similarly, if you havex <- 0 in an earlier chunk,source() will override it withx <- 1.

I read the following paragraph to imply that knitr usually evaluates in some special environment:

The default values for them may not be the appropriate environment: you may end up creating variables in the wrong environment, and being surprised that certain objects are not found in later code chunks.

If knitr usually evaluates in the global environment, then callingsource() with no arguments will usually be safe.