CRAN check failure: package 'quarto' but has not declared a SystemRequirements

[jhelvy]

We got notified from CRAN that we have several check failures:

Please see the problems shown on https://cran.r-project.org/web/checks/check_results_renderthis.html.
Please correct before 2023-10-19 to safely retain your package on CRAN.

A follow up email suggests that it has to do with the Quarto installation on CRAN:

The new check failures are because CRAN was requested to install Quarto. Your package makes use of it via package 'quarto' but has not declared a SystemRequirements (and quarto passes its checks with or without quarto-cli).

[gadenbuie]

Your package makes use of it via package 'quarto' but has not declared a SystemRequirements (and quarto passes its checks with or without quarto-cli).

I'm pretty sure this is just a snide passing comment and not at all related to the problem. If we depend on the R package quarto and quarto declares its SystemRequirements, then we should be covered. For example: does every package that uses rmarkdown declare a system requirement of pandoc? No, the fact that rmarkdown does is sufficient.

So I'm reading these emails as broadly: now that quarto-cli is installed on CRAN machines our tests are not passing.

The good news/bad news is that I can reproduce the issue locally and after some digging it seems that our tests are failing legitimately. If I dig into to_html() and turn on debugging I can see that we're trying to render the slides.qmd to output in a temporary file, but quarto is throwing

ERROR: --output option cannot specify a relative or absolute path

Error: --output option cannot specify a relative or absolute path
    at parseRenderFlags (file:///Applications/quarto/bin/quarto.js:42392:31)
    at Command.fn (file:///Applications/quarto/bin/quarto.js:90845:25)
    at Command.execute (file:///Applications/quarto/bin/quarto.js:8437:24)
    at Command.parseCommand (file:///Applications/quarto/bin/quarto.js:8333:25)
    at async quarto (file:///Applications/quarto/bin/quarto.js:127540:5)
    at async file:///Applications/quarto/bin/quarto.js:127558:9

I figured out a fix and proposed a related issue in quarto-dev/quarto-r#126

[chainsawriot]

The package is now archived on CRAN. I checked with the current r-devel using Rocker and I cannot reproduce the same errors anymore. So I think these issues are now gone.

https://cran-archive.r-project.org/web/checks/2023/2023-10-22_check_results_renderthis.html

[jhelvy]

I still see these errors. I don't know how to address this though because quarto_render() won't allow us to specify an output path. @gadenbuie any ideas? Perhaps we could disable quarto support for to_html() until this is supported by quarto_render()? We could through an error message if the user attempts to render a qmd to html, just saying that it is recommended to first render to html via quarto directly instead of {renderthis}. That will enable the package to get back on CRAN.

[gadenbuie]

I still see these errors.

Are you seeing these errors locally? IIRC this was working in CI too after #73. Maybe we should kick off a new set of checks to see if the error has resurfaced.

[jhelvy]

I still see these errors.

Are you seeing these errors locally? IIRC this was working in CI too after #73. Maybe we should kick off a new set of checks to see if the error has resurfaced.

When I run devtools::check() I get 15 test failures.

[gadenbuie]

Those are new! Looks like there have been changes in withr that have broken how we handle temporary file cleanup. Ironically, if renderthis had been on CRAN, withr would have seen our breakage with their reverse dependency checks

[jhelvy]

I mean, I appreciate that CRAN makes people keep their stuff up to date, it feels like a good overall approach to make sure the whole ecosystem is working well. But things like this then fall through the cracks if the timing is off.