How do I provide string values to params which would otherwise be parsed as numbers?

[Mosk915]

Bug description

I have a quarto document that takes parameters. One of the parameters is a character string but only contains digits. If the param being passed ends in an 8 or a 9, it converts the character string to a numeric. When it ends in any other digit, it keeps it as a character.

Steps to reproduce

---
title: "Params"
format: html
params:
  number: null
---

```{r}
print(params$number)
```

library(quarto)

quarto_render("param.qmd", execute_params = list(number = "029"))

Actual behavior

Any param that is a character string containing only digits will be converted to a numeric if it ends in 8 or 9.

Expected behavior

Character strings should not be converted to numerics ever.

Your environment

IDE: Posit Workbench 2023.12.1+402.pro1
OS: Ubuntu 20.04

Quarto check output

$ quarto check
Quarto 1.6.42
[✓] Checking environment information...
      Quarto cache location: /home/user1/.cache/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.4.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.46.3: OK
      Typst version 0.11.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.6.42
      Path: /opt/quarto/1.6.42/bin

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

[✓] Checking LaTeX....................OK
      Using: Installation From Path
      Path: /usr/local/bin
      Version: 2021

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

[✓] Checking Python 3 installation....OK
      Version: 3.12.9
      Path: /opt/python/3.12.9/bin/python3
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with python3 -m pip install jupyter

[✓] Checking R installation...........OK
      Version: 4.3.3
      Path: /opt/R/4.3.3/lib/R
      LibPaths:
        - /home/user1/R/x86_64-pc-linux-gnu-library/4.3
        - /opt/R/4.3.3/lib/R/library
        - /pkglibrary/R/4.3
      knitr: 1.47
      rmarkdown: 2.27

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

[cscheid]

This doesn't need library(quarto) (which is a separate repo https://github.com/quarto-dev/quarto-r/) to reproduce, or (in my experience) has any relation to the digits which comprise the parameter.

Presumably, your request here is to be able to differentiate the following two situations:

Examples

Number

Character

Solution

In an example with only quarto-cli involved (other examples will need a bug report at the other repo), you can achieve these two situations with the following command line parameters:

Number

$ quarto preview 12736.qmd -P number:12

Character

$ quarto preview 12736.qmd -P number:'"12"'

This is admittedly a little ugly, but it achieves the desired result. We should document this, but it's not a bug.

[cscheid]

To confirm, the same behavior works for 089:

Using -P number:'"089"'

Using -P number:089

[cderv]

quarto R 📦 uses the --execute-params which takes a YAML file. Same as -P alias for --execute-param which take YAML key:value directly.

In both cases, the type of the value will be determined by YAML parsing, following YAML 1.2 spec.

execute_params = list(number = "029") this will be written to YAML as

number: 029

And this example is a bit trickier because, depending on the YAML spec (1.1 or 1.2) and the tool that is used to parse this, it will be interpreted differently.

in yaml spec 1.1 number: 029 will be numeric, and number: 09 would be octal representation (😓)
example: https://yaml.org/spec/1.1/current.html#id858734 and https://yaml.org/type/int.html

this is with the pyyaml python package using v1.1

>>> yaml.safe_load("number: 027")
{'number': 23}

Same with R package yaml

> yaml::yaml.load("number: 027")
$number
[1] 23

But if you do 029 then this is not seen as octal anymore, and it will be character

>>> yaml.safe_load("number: 029")
{'number': '029'}

Really not easy to follow... They changed that in YAML 1.2
This is now always numeric

>>> from ruamel.yaml import YAML
... 
... yaml = YAML(typ='safe')
... yaml.version = (1, 2)  # Explicitly set YAML 1.2
>>> yaml.load("number: 027")
{'number': 27}
>>> yaml.load("number: 029")
{'number': 29}

Quarto is using 1.2 spec. This is the reason you need to use quotes.

>>> yaml.dump({'string': '029', 'number': 29}, sys.stdout)
%YAML 1.2
--- {number: 29, string: '029'}

Hope it helps understand how this works and the answer above.

That being said, there may be an issue in quarto R package to be able to write such string. This is because in R we only have yaml package, and it does only know 1.1 spec. 😞

[cderv]

To solve your problem with the current state of the tools, you need to use one of the yaml R packages tricks.

They use a system of attributes to handle specific case when writing to YAML. So you can do this

x <- "029"
attr(x, "quoted") <- TRUE
quarto::quarto_render("param.qmd", execute_params = list(number = x))

I'll see in quarto-dev/quarto-r#242 if I can make this automatically or easier

[cscheid]

This is because in R we only have yaml package, and it does only know 1.1 spec. 😞

Yikes. YAML 1.2 is 16 years old...

[mcanouil]

Almost as old as the R package^^

Version	Release
yaml_1.0.tar.gz	2008-03-21
yaml_1.0.1.tar.gz	2008-11-14
yaml_1.0.2.tar.gz	2009-08-26
yaml_1.1.0.tar.gz	2009-09-12
yaml_1.2.0.tar.gz	2011-06-17

There is a very long thread on supporting YAML 1.2: vubiostat/r-yaml#76 which turns out to be an upstream issue yaml/libyaml#20 from the YAML project itself.

[Mosk915]

@cderv , Thanks for the explanation. I do see that this is only an issue when using quarto_render via the quarto R package, so this wasn't the appropriate repo to post my issue. I did trace the issue to the R yaml package:

> yaml::as.yaml("027")
[1] "'027'\n"
> yaml::as.yaml("028")
[1] "028\n"

But based on your explanation, it sounds like this is expected behavior and there won't be any immediate fix there either. Thanks for opening quarto-dev/quarto-r#242. Hopefully this can be addressed over there.

[cderv]

it sounds like this is expected behavior and there won't be any immediate fix there either.

Yes - yaml R package expects you to write this as I shared, using attributes

yaml::as.yaml("028")
#> [1] "028\n"
x <- "028"
attr(x, "quoted") <- TRUE
yaml::as.yaml(x)
#> [1] "\"028\"\n"