YAML confusion in parametric document when Python and R are used together

[berkorbay]

Bug description

I was preparing a parametric document where title changes with respect to some parameters. I was able to do so with only python code blocks. But when I add an R code block, regardless of the position, the outcome is not desirable. It just shows the yaml as a simple code block, not actual title/subtitle etc.

Steps to reproduce

```{python}
# | tags: [parameters]
param1 = "aa"
param2 = f"bb"

---

author: "The Author" format: pdf: toc: false number-sections: false execute: echo: false warning: false message: false

# | output: asis
print(
    f"""
---
title: "Some title ({param1},{param2})"
---
"""
)

library(reticulate)
library(tidyverse)

ps. Remove the R chunk to get a proper render.

### Expected behavior

It should work normally and display title and author. 
<img width="518" alt="Screenshot 2024-06-23 at 16 23 00 1" src="https://github.com/quarto-dev/quarto-cli/assets/5690139/a87a6d55-2de0-47c4-9fec-2122a37c662d">

### Actual behavior

When R chunk is included it does not display anything but codeblocks with only the title

<img width="512" alt="Screenshot 2024-06-23 at 16 21 53" src="https://github.com/quarto-dev/quarto-cli/assets/5690139/98d1e0ad-b828-4bc4-b52d-369d7668bbae">

### Your environment

VSCode Version: 1.90.0 (Universal)
Commit: 89de5a8d4d6205e5b11647eb6a74844ca23d2573
Date: 2024-06-04T19:34:44.157Z (2 wks ago)
Electron: 29.4.0
ElectronBuildId: 9593362
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 22.1.0

Apple M1 Max
MacOS Ventura 13.0.1

### Quarto check output

Quarto 1.4.555
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.11: OK
      Dart Sass version 1.69.5: OK
      Deno version 1.37.2: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.4.555
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: (not installed)
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: Installation From Path
      Path: /opt/homebrew/bin
      Version: undefined

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.11.6
      Path: /Users/rocket/.pyenv/versions/3.11.6/bin/python3
      Jupyter: 5.7.1
      Kernels: python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.3.1
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library
      knitr: 1.43
      rmarkdown: 2.24

[✓] Checking Knitr engine render......OK

[berkorbay]

I realized it is mainly because when R chunks are included engine becomes knitr. My interim solution is to use only R variables in the YAML.

[mcanouil]

As explained in the documentation, you cannot use two engines. When there is an R code cell, then if no engine was specified, it means knitr. If only Python code cells, it means Jupyter.

knitr engine is using reticulate to run Python code. Jupyter engine has nothing by default to execute R code, so you need to install a Python module for that. So set the engine you want to use to configure it.

Note that Quarto/Pandoc expect the metadata YAML block to be the first thing in the document (even if Pandoc allows multiple YAML block that are then merged together).

Also note that title is used for several things that occur early in the process.

To me there is no bug here.

[mcanouil]

Side question: why changing the metadata using computational parameters while you can directly change the metadata in the CLI? (See quarto render --help)

[berkorbay]

I do not want to use two engines. But I would expect the parametric YAML behavior to stay the same because the engine switch is automatic. knitr breaks python manipulation of YAML as shown in the MWE. metadata block is the first thing in the YAML, defined with python.

It is not actually a bug, but an undesired consequence of automatic engine switching. But I had only two options when reporting an issue 🙃

[berkorbay]

Side question: why changing the metadata using computational parameters while you can directly change the metadata in the CLI? (See quarto render --help)

My current settings and habits are different but I'll keep it in mind. I did not think it would be possible to change title from the CLI.

[mcanouil]

As answered, set the engine yourself: engine: whatever

Quarto only uses knitr/reticulate and has basically no control on them.

[mcanouil]

Also, the issue is that "Black" and other Python formatter don't want to make exception for #| comment syntax, which means when you format your code cell it becomes # |. Since formatters did not want to handle that, Quarto allowed it for Jupyter engine but knitr does not know that.

I also highly suggest you keep the YAML block as the first thing in your document otherwise you'll lose auto-completion from various editors such as VSCode, VIM, and RStudio.

Input	Output
````qmd --- author: "The Author" format: pdf: toc: false number-sections: false execute: echo: false warning: false message: false engine: knitr --- ```{python} #| tags: [parameters] param1 = "aa" param2 = f"bb" ``` ```{python} #| output: asis print( f""" --- title: "Some title ({param1},{param2})" --- """ ) ``` ```{r} library(reticulate) ``` ````

[berkorbay]

Ah, I did not know a space between "#" and "|" would make such a difference. 💡 Then it solves my issue.

[mcanouil]

I’m reopening as there might be something that could be done related to # | on Quarto/knitr.

[cscheid]

https://github.com/quarto-dev/quarto-cli/issues/8698

[cderv]

Also, the issue is that "Black" and other Python formatter don't want to make exception for #| comment syntax, which means when you format your code cell it becomes # |. Since formatters did not want to handle that, Quarto allowed it for Jupyter engine but knitr does not know that.

If we need to allow this for knitr engine in Quarto context, I think we can do that. but I did not know we supported # | for Jupyter engine in the first place.

[mcanouil]

It was done because Python formater such as Black would break the cell every time if it was not supported. The PR to allow #| was dismissed (if I recall it was even before Quarto first release)