Add a function to check if a newer quarto is available

[cderv]

I have two more feature requests for quarto R package.

(1) In the quarto R package, can the message for quarto_version() function be more informative? Currently it shows simple message like "1.2.15". Can it be changed to "Your quarto version is 1.2.15. The latest available version is 1.2.75."

(2) After such a message, if the user wants to update the quarto version, he/she has to manually update the version through quarto website. Is it possible to create a function within quarto package so that the user can directly update the quarto version right from within RStudio or VSCode? This is in line with function tinytex::tlmgr_update(), which updates Latex packages from within RStudio.

Originally posted by @bhattmaulik in quarto-dev/quarto-cli#2374 (comment)

[bhattmaulik]

Thanks a lot for this. One more idea for this function: also include an argument "include_beta", which might be set to FALSE by default. As far as I am aware, in the quarto, the odd number release is a stable release (e.g., 1.1.X), and even number release is beta or experimental (e.g.., 1.2.X). So, if a person like me wants to experiment with the experimental release, I can set it to TRUE when I want to download a new release.

[mcanouil]

I have R code to check latest GitHub tag of a given repository and from that it's kind of trivial to access release assets (instead of Quarto website).
The tricky part, is the install part of the asset downloaded (i.e., permission, etc.).
Also, this would not rely on system package/library manager (Homebrew, Scoop, etc.).
So, I would simply point to the release assets and once the different install processes have been described on Quarto's website, add a link to that resource to aim the user to the right direction to update appropriately his/her Quarto binary.

I'll probably make a PR for that (not the install part).

[cderv]

@bhattmaulik 1.1 is currently the latest stable release and 1.1.X are patches only on it. 1.2 is the next release, currently in pre-release phase. Some new features and patches can be added until it is release to stable. Then 1.3 will probably be the next pre-release, and so on. We don't have odd and even release scheme yet.

@mcanouil We have some installation function is other package like tinytex or blogdown, so we could think of adding that. installr is another package on CRAN that offers installation of tools. So it seems possible. However, it is always hard work to support installation process on different OS from R. We could try, but maybe pointing to the right url would help more.

Also on more general thoughts, quarto R package should not be used quite often as you don't need the R package to run Quarto.

I'll think more about that.

I have R code to check latest GitHub tag of a given repository and from that it's kind of trivial to access release assets (instead of Quarto website).

The best way to check the last version available is to use the JSON endpoint of the download page.

jsonlite::fromJSON("https://quarto.org/docs/download/_download.json")$version
#> [1] "1.1.189"

No need to query GH and check latest tag.

[mcanouil]

We could try, but maybe pointing to the right url would help more.

with tinytex or blogdown (i.e., HUGO), the tools are installed in some isolated environments to avoid conflicts or messing up the system-wide install if any.
Implementing an install function, makes sense to me only under the same circumstances, i.e., there is no way to know how Quarto CLI was installed regardless of the OS, thus there is no way to update without messing up the installation by for example having several Quarto CLI versions installed with some accessible from terminal while some accessible only through quarto/R.
Having quarto able to install Quarto CLI feels highly insecure and I would personally never use such function unless I have guarantees it: overwrite previous version I have using the same install workflow (Homebrew, Scoop, etc.) and that this version is available to R and terminal.
For shorts, I would only redirect user to the documentation website and let him/her do the job (he/she was supposed to do first).

Also on more general thoughts, quarto R package should not be used quite often as you don't need the R package to run Quarto.

Rare are my use cases where I first use the R package, but targets depends on the R package quarto (https://github.com/ropensci/tarchetypes/blob/main/R/tar_quarto_raw.R#L274), so the frequency might be high for all targets users switching from rmarkdown to Quarto.

Another note, if a newer version is detected, what I think would be the best (especially for a use in targets or other workflow):

1. a message (not a warning)
2. the 6-hour interval thing between messages as in some of the tidyverse packages.

[cderv]

Yes I agree with you that is is not ideal to have an install function from R. As I said not easy to do and maintain.
Also, quarto R package is not needed to use Quarto, so not sure it makes sense. However, I said that it can be done in a Package like installr but it targets Windows only.

Thanks for sharing your detailed thoughts on this.

Regarding version detection, I shared thoughs in quarto-dev/quarto-cli#2374 (comment) and not put it here, but I think we should have a specific function and not have quarto_version() prints a message.

we could indeed add a check function in quarto R package. I'll add an issue there for a quarto_check_version() or something like that. (quarto_version() is really meant to check minimum requirement in code to test against version so we don't want to add more verbose in that).