A Change in the Meaning of the Chunk Option message = FALSE / warning = FALSE | /en/2022/12/message-false/

[giscus[bot]]

A Change in the Meaning of the Chunk Option "message = FALSE" / "warning = FALSE"

With a new release of the evaluate package (v0.19) last week, the meanings of the chunk option message = FALSE and warning = FALSE in knitr have changed. Previously, they meant that messages and …

https://yihui.org/en/2022/12/message-false/

[gadenbuie]

Hi! This is a nice improvement but I know that you obviously expected someone to be interested in redirecting warnings and messages to the console, so I’ll go ahead and be that person! 😇

I agree with you that the option values were unintuitive, but I frequently use the console output to diagnose or record problems in otherwise hard to reach places. For example, it’s extremely handy when rendering documents in a non-interactive environment like CI. It’d be great to have a way to opt into the old behavior.

[yihui]

Feel free to be that person, and you will definitely get what you want in the next version of evaluate! :) I'll keep you posted. Thanks for the feedback!

[yihui]

With the dev versions of evaluate and knitr, you can go back to the old behavior with message = NA and warning = NA:

remotes::install_github(c('r-lib/evaluate', 'yihui/knitr'))

[grimbough]

Bit late to the party, but are the message and warning options only expecting to be passed logicals? Prior to this change I passed character vectors of warnings that I expected to see in a code chunk, and used a custom knit_hooks$set(warning = "...") to suppress those expected outputs, but retain anything new that cropped up.

There's some crude examples at https://support.bioconductor.org/p/9141044/

With the new evaluate version I'm getting a variety of errors like below, presumably because keep_warning is expecting a logical and not anything else.

Error in keep_warning && getOption("warn") >= 0 : 
  invalid 'x' type in 'x && y'

[yihui]

Allowed values of message and warning options are documented at https://yihui.org/knitr/options/#text-output They can only take logical and numeric values. Character values worked by chance previously because they were treated as TRUE (yihui/knitr@5ff3888).

In your example, I suggest you rename options$warning to something like options$known_warning to avoid overloading the chunk option warning, and use the chunk option known_warning to pass the character vector of known warnings. Sorry about the hassle!

[grimbough]

Thanks for the reply. I had a feeling we might have been abusing the warning option and getting away with it by chance. Adopting the strategy you suggested works great, and I've updated the example at https://support.bioconductor.org/p/9141044/#9149469 in case anyone else stumbles across it.

[yihui]

Great! Thank you very much!

[slodge-work]

I'm currently in the process of updating a large number of RMarkdown reports spread across a lot of repos to R4.3 - and I'm taking the opportunity to update their renv.lock files to modern tidyverse and rmarkdown/knitr as I go.

This area is causing me some challenges with our debug and monitoring logging at the moment.

We've traditionally setup our RMarkdown's so that they use a Log function which is a basic wrapper of message to output status information which helps us identify what's broken when an Rmd rendering job fails on our production servers - e.g. we might have blocks like:

---{r datafetch, message=FALSE, warning=FALSE}
Log("Fetching data for", param$code, "on", param$report_date)
data <- httr_fetch_for_data(some_url)
Log("Data fetched", nrow(data))
# ... data shaping, presentation added, etc
Log("Shaped data complete", nrow(some_shaped_data))
gt:gt(some_shaped_data) |> formatted()
---

On upgrading to the latest evaluate and knitr, this functionality now seems to be broken - our report knitting just outputs minimal debug info. We've found we can get some of the previous info back by call knitr::chunk_opts$set(message = NA, warning=NA) in our job processing code which is called before rmarkdown::render().

However, this doesn't seem to entirely work for us - especially because many of our Rmd's also have local overrides in place - e.g. many report authors have added knitr::chunk_opts$set(message=FALSE) lines or have used {r cars, message=FALSE} blocks locally in their R code in order to make their reports look beautiful during local debugging - and these local overrides replace our global NA setting.

If necessary, we can go through all these reports and replace all the blocks with e.g. {r cars, message=NA} but I'm wondering if this is really the right way to go. Is there any way we can instead set a global override here to ensure all message and warning information is passed to the console? As someone who often has to find out where problems are, I've always appreciated and used the console message output, and I would really appreciate having a global "please be verbose" setting that I can turn back on without having to go in and edit lots of individual Rmd blocks - plus trying to retrain lots of users who've got very used to adding message=FALSE.

PS I appreciate I'm also late to the discussion here too - renv has done a magnificent job of providing us with version stability this year, but it does mean we don't notice problems like this very quickly after package updates :)

[slodge-work]

I was thinking I want a stronger option than that - I want an option that reverts the package to the old console logging behaviour regardless of any message=FALSE existing in code - i.e. similar to the setHook code.

But if it's not something we want to add to the package then no worries (y)

[yihui]

Oh I see what you mean now. In theory, I could add an env var. It should be a fairly simple change in either knitr or evaluate. Let me think more for a moment.

[yihui]

Done via r-lib/evaluate@ee0fa82. You can set R_EVALUATE_BYPASS_MESSAGES=true to get what you want.

[slodge-work]

Thanks.

I do expect this will be very useful for Connect users who want to get some temporary verbose output 👍

[yihui]

FYI the new version of evaluate is on CRAN now: https://cran.r-project.org/package=evaluate