source() script at start of document

[baptiste]

Maybe I missed an option to do this, but I'm thinking it would be nice if we could specify in the Yaml header a script to be executed at the start of the knitting process (I'm using R/knitr as a concrete example, but the same idea would presumably apply to other engines). Unlike pre-render project scripts, the purpose here is would be to set up the environment for the computations, e.g loading packages, setting options, doing some calculations for use in subsequent chunks, etc.

Of course, this is trivially achieved with a first chunk,

```{r setup, echo=FALSE}
library(ggplot2)
phig_ratio <- function(n){
  if(n<=2) { if(n>=0) 1 else 0 } else 1 + 1 / Recall(n-1) 
}
fig_height = 6 * phig_ratio(100)
data = read.csv('mydata.csv')
# ...
```

but there are some types of prose-first documents where I would prefer to have this happen less prominently, as a background process, rather than the first thing that I read when I work on the document. I find it a bit distracting, when writing prose, to be facing first not the abstract, or the first section title, introduction, etc. but obscure lines of code that are not necessarily things I should be thinking about, and which inadvertently force my brain to switch to coding mode, so to speak.

I would rather have an option in the header,

-----
title: ....
date: ....
init-chunk: 
  - setup.R
-----

## This is the content

In this essay, I will

```{r, fig.height = fig_height, eval = "totoro" %in% names(data) }
# ...
```

I ran into this when creating CVs, posters, exam papers, cover letters, etc. in Quarto; for these types of output the computations, often minimal, are there in the background to support the document and help construct it (e.g grabbing size information from image files, etc.), but I want to see them as little as possible.

[cscheid]

It's unlikely that we'll do this because it requires working uniformly across engines. But if your main concern is readability, you can start with an include shortcode:

{{< include preamble.md >}}

and then preamble.md has the r code cell:

```{r setup, echo=FALSE}
library(ggplot2)
phig_ratio <- function(n){
  if(n<=2) { if(n>=0) 1 else 0 } else 1 + 1 / Recall(n-1) 
}
fig_height = 6 * phig_ratio(100)
data = read.csv('mydata.csv')
# ...
```

[baptiste]

Thanks – fair enough, I can live with the workarounds (I'm using source("setup.R") but I should try this include, it reads more like text).

[mcanouil]

@baptiste I am going to change this to "Q&A" and mark the reply above as the answer.

[cderv]

Just adding some other solutions for knitr users having a R file to run as a setup chunk (to complement other answer in this thread)

The file chunk option is valid and allow to use R file as code chunk content (https://bookdown.org/yihui/rmarkdown-cookbook/option-code.html)

```{r}
#| label: setup
#| echo: false 
#| file: setup.R
```

This can be added in all chapter.

Using include shortcode is more of a Quarto way and allows much more than a R file only as setup.

A R only workaround for auto running some R code before any R code is using a project .Rprofile. Quarto will start a new R process for each document, and it is possible to leverage R own startup feature for this. Advanced User only I would say but quite valid anyway. To learn more: https://rstats.wtf/r-startup.html

[mcanouil]

Note that your .Rprofile can be at the root of your project next to _quarto.yml and be versioned using Git for example.
This is the behaviour when using renv.

[cderv]

I don't know for Julia and Python how that would work exactly because they are running Jupyter under the hood. Would a Python or Julia Startup script be taken into account inside Jupyter kernel execution ?

knitr does execute in the R started session at the global level so this is easy, but for Python, it starts Jupyter and then start a kernel.
Especially for Julia where we do not run Julia directly. My understanding is We start Jupyter in Python which will run a Julia Kernel.

I don't know enough to know as of now what could be done for Python and Julia. That is also why the setup chunk or the use of include shortcode is the more common way of doing this. Drawback is you need to paste this include statement or setup chunk inside all your Qmd.

[allefeld]

An idea how to implement this in an across-engines way:

Have a YAML option initial-block: "init.EXT" which points to a file within the project, where EXT is the appropriate code file extension (R, py, etc.) for a language. If the file extension matches the currently running engine & kernel language, this setting is equivalent to having an executable code block

```{LANGUAGE}
#| include: false
{{< include init.EXT >}}
```

inserted before all document content.

Advantages over actually including such a block in a document:

• less boilerplate, document better readable by moving init code into a file referenced in the header
• can also be used in _quarto.yml or within a custom format, etc.

To avoid possibly error-prone guessing of the language from the file extension, the syntax could be

initial-block:
  language: r
  file: "init.R"

To cover several languages at once e.g. in _quarto.yml, this option could be nested under knitr: and jupyter: or even kernelspec:.

[cderv]

Thanks a lot @allefeld that is an interesting idea!

[allefeld]

Thanks!

Even simpler:

initial-block:
  r: "init.R"
  python: "init.py"
  …

The setting for a language is effective if there are any executable code blocks ```{language} already in the document.