Is Quarto meant to support knitr::read_chunk in a book chapter?

[harrelfe]

I have a book chapter in which I have the R code in a separate file shared.R in knitr::read_chunk's expected format, e.g.

|##@knitr foo
|... code ...

Then in the .qmd file:

```{r setup}
knitr::read_chunk('shared.R')
```
. . . . .

```{r foo}
```

to run the code. I'm getting an error that a data table created inside foo is not found when a later R code piece in shared.R that uses that data table is invoked from .qmd.

Before submitting a bug report with a reproducible example is Quarto intended to do this, when doing a book?

[mcanouil]

Would it be possible to have a fully reproducible example?
I personally now have a repository with different issues as independent directory: https://github.com/mcanouil/quarto-issues
This makes thing easier for anyone to try and not to guess.

EDIT: Below a reproducible example for standalone HTML document (from https://bookdown.org/yihui/rmarkdown-cookbook/read-chunk.html) in which it works.

See the code.

• demo.qmd

  ---
  title: "Test"
  format: html
  ---
  
  Read an external script:
  
  ```{r}
  #| include: false
  knitr::read_chunk("shared.R")
  ```
  
  Now we can use the code, e.g.,
  
  ```{r test-a}
  #| echo: false
  ```
  
  ```{r test-b}
  #| fig.height: 4
  ```

• shared.R

  ## ---- test-a --------
  1 + 1
  
  ## ---- test-b --------
  if (TRUE) {
    plot(cars)
  }

[harrelfe]

Sorry the way my examples originate lately is from converting large chapters from LaTeX or RMarkdown to Quarto which makes it sometimes hard to isolate problems. The alias is not interacting with this problem so I should have just used fig.cap which would result in the same problem. For now I'll assume that chunk labels need to be "big" e.g. fig-chaptername-figurename even though I would have expected chaptername-figurename to have worked (it didn't) exept that #| label: fig-chaptername-figurename is required.

[mcanouil]

I'll try later to see if can make something that reproduce this behaviour.

[harrelfe]

In running a lot of tests (but still being unable to put together a simple reproducible example) I have found the read_chunk() approach to be unreliable in Quarto. Some scope is being lost, i.e., earlier chunks that produced new objects that I would have been sure were stored in the .globalEnv gave rise to later chunks not finding those new objects.

[mcanouil]

I should have a bit of time in the next few days to try to reproduce what you have.
Meantime if you don't have a small reproducible example, does your book happen to be on a public repository on GitHub?

[harrelfe]

It will be public on Github but not yet.

[jimjam-slam]

An alternative to knitr::read_chunk could be to use an Include!

I think Quarto shortcodes are processed before computations happen, so you could theoretically either include the content of a single chunk, like:

Blah blah blah...

```{r}
{{ < include script.r > }}
```

Or include one or more chunks as a `.qmd file:

Blah blah blah...

{{ < include script.qmd > }}

(You might need to confirm that my understanding is correct, though!)

EDIT: my bad! @cscheid says Lua filters happen after knitr/jupyter.

[cscheid]

@jimjam-slam so there's an extra wrinkle here.

Lua filters happen after knitr/jupyter, but {{< include >}} is not a lua filter. include happens to be specially implemented, exactly because we expect people to want to include computational content in their includes. I should have clarified, sorry!

[jimjam-slam]

Oh, awesome! Sounds like it could be a viable alternative, then! 😊