Feature request - Return Quarto version

[jthomasmock]

In theory it's possible to have different versions of quarto available via the terminal versus what version the RStudio IDE + Render button or quarto::quarto_render() default to.

quarto::quarto_path() is a useful upstream step, but it would be great to also return the quarto version that R/RStudio are currently using.

[cderv]

In theory it's possible to have different versions of quarto available via the terminal versus what version the RStudio IDE + Render button or quarto::quarto_render() default to.

You mean that the version used for Quarto in RStudio will not be the same as in Terminal ?
I think it should be the same used as the IDE will use the version in PATH if any.

quarto::quarto_path() is a useful upstream step

This function will return the version found by Sys.which() or the one set with QUARTO_PATH environment variable. I don't know how it relates with RStudio one.

We could return the path of the version bundled with RStudio IDE as we should know where it is but as I said, I don't think this is the one that will used if there is another one set in PATH. (the one accessible from Terminal)

[jthomasmock]

My current understanding is that there are 3 ways of defining quarto "preference". The overlapping option is latest version of Quarto on $PATH.

1. In RStudio

• RStudio IDE > Render button will use RSTUDIO_QUARTO env var with higher priority than latest version on path $PATH
• RStudio IDE > Render button will search $PATH for newest version of quarto unless overridden byRSTUDIO_QUARTO

2. Via quarto R Package

• quarto::quarto_path() will use QUARTO_PATH env var as priority over latest version on $PATH
• quarto::quarto_path() will use equivalent of R Sys.which("quarto")

3. In Terminal

• Terminal will use latest version of Quarto on $PATH as defined in a .bashrc or other .profile equivalent.
• Terminal can temporarily use direct path to Quarto executable even if not on $PATH
• Terminal can be overridden to interactively use alternative/older version of Quarto via an alias (not propagated to R/RStudio, since not reflected in $PATH)

Questions:

• Does it make sense to have RStudio (ie a GUI to R) respect the Quarto R package QUARTO_PATH rather than having it's own .Renviron variable?
• Related to original query - can quarto R package return the Quarto version? That would help with confirmation that version in use is intended version.

[ronblum]

As a comparison point, markdown::pandoc_version() and rmarkdown::find_pandoc() inform which version of pandoc is used. I think these are using the pandoc executable?

> rmarkdown::pandoc_version()
[1] ‘2.18’
> rmarkdown::find_pandoc()
$version
[1] ‘2.18’

$dir
[1] "/Applications/RStudio-2022.06.0-daily-530-OG.app/Contents/MacOS/quarto/bin/tools"

[cderv]

I think these are using the pandoc executable

rmarkdown::pandoc_version() uses the pandoc CLI to get the version using pandoc --version. The binary used is the one returned by rmarkdown::find_pandoc() which is the latest version between the version provided by RStudio (RSTUDIO_PANDOC env var) and any found in PATH.

Here by Quarto version, I think @jthomasmock meant something like rmarkdown::find_pandoc() where the PATH to the quarto version used (By the IDE ?) is returned. For now heuristic in both package and IDE may differ 🤔

[cderv]

@jthomasmock if what you are looking for is rather something to diagnose things like usethis::git_sitrep() or blogdown::check_site()

Currently quarto_path() powers find_quarto() and quarto_version() and it will only consider the version used by the R package which is QUARTO_PATH or Sys.which("quarto")

So either we do add another unrelated function that would help understand what R and RStudio see, based on #12 (comment)

or we do adapt how the R package works and maybe add support for RSTUDIO_QUARTO ?

Currently you can get the quarto_render() situation with

quarto::quarto_path()
#> [1] "C:\\Users\\chris\\scoop\\shims\\quarto.exe"
quarto::quarto_version()
#> [1] '1.4.549'

^{Created on 2024-01-24 with reprex v2.0.2}

[jthomasmock]

Thanks @cderv !

I had spoken briefly with @dragonstyle about moving towards combining QUARTO_PATH and RSTUDIO_QUARTO but I agree that the goal is more of a sitrep than just a manual version return.

In the current state where Quarto is configurable in RStudio in the 3 ways ($PATH, RSTUDIO_QUARTO, QUARTO_PATH), sitrep would parse all 3 and confirm they're the same 😄

But I do wonder if we'd also want to move towards a world where RSTUDIO_QUARTO is gone and it's just QUARTO_PATH and $PATH. That would ensure that at least the RStudio UI and R itself should be aligned.

[cderv]

But I do wonder if we'd also want to move towards a world where RSTUDIO_QUARTO is gone and it's just QUARTO_PATH and $PATH. That would ensure that at least the RStudio UI and R itself should be aligned.

We definitely could. It is easy enough to support RSTUDIO_QUARTO in R package in addition or instead of QUARTO_PATH.

For changing RSTUDIO_QUARTO to QUARTO_PATH, I believe this is a IDE thing, and I don't know the schedule on that.

We can add a quarto_bin_sitrep() in this package to help maybe ?