Odd scope error rendering in Quarto but not for `rmarkdown::render`

[matthew-brett]

I have run into a strange error rendering in Quarto that appears to be a scope problem. I do not see the same error when rendering in rmarkdown::render.

Consider the following document (also at https://github.com/matthew-brett/quarto-test-book/blob/main/intro.Rmd):

```{r}
source('setup.R')
# Contains only the following function:
# get_var <- function(name) {
#   return (get(name))
# }
```

```{r}
# Redefining the exact same function here fixes error below.
# get_var <- function(name) {
#   return (get(name))
# }
```

```{r}
p <- 1
```

```{r}
# No error
get('p')
```

```{r}
# Error here:
# Error in get(name) : object 'p' not found
# Calls: .main ... withCallingHandlers -> withVisible -> eval -> eval -> get_var -> get
get_var('p')
```

See the noted error in the last chunk, generated by quarto render.

There is no error for Rscript -e "rmarkdown::render('intro.Rmd')", and I get the expected output ([1] 1).

Is there something different about the scope or environment when executing via Quarto?

[jjallaire]

Interesting! Thanks very much for reporting. The issue seems to be that even though rmarkdown/knitr can in theory be run within any environment, there is a tacit dependency on running in the globalenv() for calls to the get() function within a source(). For example, the following gives the same error you see in Quarto in R Markdown:

renderit <- function() { rmarkdown::render("quarto-getvar.Rmd") }
renderit()

This normally works because the default environment for rmarkdown::render is parent.frame() (which from the REPL is the global environment and from the RStudio Knit button is also the global environment).

It seems like the call to source() is defining the function within the global environment, which means that the call to get() within looks in the global environment and doesn't find p there. I think we need to find a way for quarto to call rmarkdown::render within the global environment.

cc @yihui In case any of this is surprising to you.

[jjallaire]

Should be fixed here: 0ae97bd

[matthew-brett]

Thanks for the fix.

[yihui]

That's because source() executes code in the global environment by default (which I believe is a bad default). In this case, you have to call

source('setup.R', local = TRUE)

[matthew-brett]

Thanks for the clarification. @jjallaire - should I rely on the new default, or change all instances of our version of source('setup.R') to source('setup.R', local = TRUE)?

[jjallaire]

I think it’s safe to rely on the default, but you should know that if you ever render from outside of the global environment in traditional rmarkdown then this code won’t work as-is (you’d need Yihui’s suggested change to make it work in any environment)

…

On Tue, Oct 12, 2021 at 10:33 AM Matthew Brett ***@***.***> wrote: Thanks for the clarification. @jjallaire <https://github.com/jjallaire> - should I rely on the new default, or change all instances of our version of source('setup.R') to source('setup.R', local = TRUE)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZPR7J65YLXVALHYKGHO3UGRBLFANCNFSM5FV2CITA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.