[Rmd] Rendering on Connect fail while knitting locally works

I'm still trying to figure why rendering on connect fails and knitting locally works.

Example Rmd

```{r cars}
bob <- "carb"
library(gt)
gt(mtcars) |>
  cols_label(contains(bob)~bob)
`` `
Error in `resolve_cols_i()`:
! Problem while evaluating `contains(bob)`.
Caused by error:
! object 'bob' not found
Backtrace:
  1. gt::cols_label(gt(mtcars), contains(bob) ~ bob)
 22. tidyselect::contains(bob)
 23. tidyselect:::check_match(match)
 24. rlang::is_character(match)
Execution halted
Unable to render the deployed content: Rendering exited abnormally: exit status 1

But you can do an eval parse and it will work.

col_labels(eval(parse(text = "contains(%s)~%s" |> sprintf(bob, bob))))

I'm thinking is some funky env eval going on.

Full stacktrace

 1: cols_label(gt(mtcars), contains(bob) ~ bob)
 2: resolve_cols_c(expr = !!cols, data = .data)
 3: resolve_cols_i(expr = {
    {
        expr
    }
}, data = data, 
 4: suppressWarnings(tidyselect::eval_select(expr = quo, data = d
 5: withCallingHandlers(expr, warning = function(w) if (inherits(
 6: tidyselect::eval_select(expr = quo, data = data, strict = str
 7: eval_select_impl(data, names(data), as_quosure(expr, env), in
 8: with_subscript_errors(out <- vars_select_eval(vars, expr, str
 9: try_fetch(expr, vctrs_error_subscript = function(cnd) {
    cn
10: withCallingHandlers(expr, condition = function(cnd) {
    {
   
11: vars_select_eval(vars, expr, strict = strict, data = x, name_
12: walk_data_tree(expr, data_mask, context_mask)
13: eval_context(expr, context_mask, call = error_call)
14: with_chained_errors(eval_tidy(as_quosure(expr, env), context_
15: try_fetch(expr, error = function(cnd) {
    eval_expr <- quo_s
16: tryCatch(withCallingHandlers(expr, condition = function(cnd) 
17: tryCatchList(expr, classes, parentenv, handlers)
18: tryCatchOne(expr, names, parentenv, handlers[[1]])
19: doTryCatch(return(expr), name, parentenv, handler)
20: withCallingHandlers(expr, condition = function(cnd) {
    {
   
21: eval_tidy(as_quosure(expr, env), context_mask)
22: contains(bob)
23: check_match(match)
24: is_character(match)
## R version 4.3.2 (2023-10-31)
## Platform: x86_64-pc-linux-gnu (64-bit)
## Running under: Ubuntu 22.04.3 LTS
## 
## Matrix products: default
## BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 
## LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;  LAPACK version 3.10.0
## 
## locale:
##  [1] LC_CTYPE=C.UTF-8       LC_NUMERIC=C           LC_TIME=C.UTF-8       
##  [4] LC_COLLATE=C.UTF-8     LC_MONETARY=C.UTF-8    LC_MESSAGES=C.UTF-8   
##  [7] LC_PAPER=C.UTF-8       LC_NAME=C              LC_ADDRESS=C          
## [10] LC_TELEPHONE=C         LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C   
## 
## time zone: America/Montreal
## tzcode source: system (glibc)
## 
## attached base packages:
## [1] stats     graphics  grDevices utils     datasets  methods   base     
## 
## other attached packages:
## [1] gt_0.10.0
## 
## loaded via a namespace (and not attached):
##  [1] vctrs_0.6.5      cli_3.6.2        knitr_1.45       rlang_1.1.2     
##  [5] xfun_0.41        generics_0.1.3   jsonlite_1.8.8   glue_1.6.2      
##  [9] htmltools_0.5.7  sass_0.4.8       fansi_1.0.6      rmarkdown_2.25  
## [13] evaluate_0.23    jquerylib_0.1.4  tibble_3.2.1     fastmap_1.1.1   
## [17] yaml_2.3.8       lifecycle_1.0.4  compiler_4.3.2   dplyr_1.1.4     
## [21] pkgconfig_2.0.3  digest_0.6.33    R6_2.5.1         tidyselect_1.2.0
## [25] utf8_1.2.4       pillar_1.9.0     magrittr_2.0.3   bslib_0.6.1     
## [29] tools_4.3.2      xml2_1.3.6       cachem_1.0.8

Are the versions of the packages the same locally and on connect ?

Yes, of course, first think I checked. Something is going on with env.

I found the same issue when using {pointblank} (same package author) and Connect, specifically when using objects in the "preconditions" argument. The following will work locally but not when deployed on Connect:

bob <- "carb"
library(pointblank)
mtcars %>%
  col_vals_gt(columns = 1,
              value = 0,
              preconditions = ~. %>% dplyr::select(contains(bob)))
Error in `dplyr::select()`:
! Problem while evaluating `contains(bob)`.
Caused by error in `is_character()`:
! object 'bob' not found
Backtrace:
  1. mtcars %>% ...
 30. tidyselect::contains(bob)
 31. tidyselect:::check_match(match)
 32. rlang::is_character(match)
Execution halted
Unable to render the deployed content: Rendering exited abnormally: exit status 1

However, changing the formula syntax to a function in preconditions will work:

preconditions = function(x) x %>% dplyr::select(contains(bob)))

Could this be stemming from rlang::eval_tidy()?

Something is definitely not correct with tidyselect and contains() check.

As this works locally, and not on connect, I am still puzzled that this would happen under

  • The same R version
  • The same packages version

Is this possible to download the bundle that has been uploaded on connect to get access to the manifest, and which packages are restored ? the log file may be a good place too ?

@michaelbgarcia is this the same for you ? Work locally but not when deployed ?

I'll verify everything again and attach bundle files for debugging on your side.

So this won't knit but will run fine in console.

---
title: "testing"
output: html_document
date: "2024-01-15"
---

```{r cars}
library(gt)
bob <- "carb"
gt(mtcars) |>
  cols_label(contains(bob)~bob)
`` `
> sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.3 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;  LAPACK version 3.10.0

locale:
 [1] LC_CTYPE=C.UTF-8       LC_NUMERIC=C           LC_TIME=C.UTF-8        LC_COLLATE=C.UTF-8    
 [5] LC_MONETARY=C.UTF-8    LC_MESSAGES=C.UTF-8    LC_PAPER=C.UTF-8       LC_NAME=C             
 [9] LC_ADDRESS=C           LC_TELEPHONE=C         LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C   

time zone: America/Montreal
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] gt_0.10.0

loaded via a namespace (and not attached):
 [1] vctrs_0.6.5       cli_3.6.2         knitr_1.45        rlang_1.1.3       xfun_0.41        
 [6] generics_0.1.3    glue_1.7.0        htmltools_0.5.7   vabene_1.0.5      sass_0.4.8       
[11] fansi_1.0.6       rmarkdown_2.25    evaluate_0.23     tibble_3.2.1      fastmap_1.1.1    
[16] yaml_2.3.8        lifecycle_1.0.4   compiler_4.3.2    dplyr_1.1.4       pkgconfig_2.0.3  
[21] rstudioapi_0.15.0 digest_0.6.34     R6_2.5.1          tidyselect_1.2.0  utf8_1.2.4       
[26] pillar_1.9.0      magrittr_2.0.3    tools_4.3.2       withr_2.5.2       xml2_1.3.6     
> rmarkdown::render("./testin.Rmd")


processing file: testin.Rmd
  |...........................................................................................| 100% [cars]
Quitting from lines 10-14 [cars] (testin.Rmd)
Error in `parse()`:
! attempt to use zero-length variable name
Backtrace:
  1. rmarkdown::render("./testin.Rmd")
  2. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  3. knitr:::process_file(text, output)
  8. knitr:::process_group.block(group)
  9. knitr:::call_block(x)
     ...
 11. knitr:::eng_r(options)
 14. knitr (local) evaluate(...)
 15. evaluate::evaluate(...)
 17. evaluate:::parse_all.character(...)
 18. base::parse(text = x, srcfile = src)

Hey all, I'm a tad late to the party here but I have a problem with quarto and publishing to posit connect in Rstudio.

added one bit of code (mermaid diagram) and the code failed to compile. It says no chromium even though it is installed on my system (verified).

So, file compiles locally - no problem. When I try to publish to posit connect, it fails.

Bug? I filed a bug report but I thought it was an rstudio problem; instead, I think it is an RStudio problem with posit connect.

Am I missing something here? No package version conflicts since I have no R code - only ONE mermaid segment.

Thoughts?

Yup I can knit locally (different than what @meztez is experiencing) but fails when deploying to Connect. I'll take a look at logs and the bundles as well. I don't want to interfere with the original reported issue by @meztez so I'm happy to make a separate thread if needed

@michaelbgarcia Have you updated connect and workbench to December 2023 releases?

Not yet, we are currently on Version 2023.10.0 for Connect and Version 2023.03.0 for Workbench/Rstudio Pro

I can reproduce this with the document provided as example at above

---
title: "testing"
output: html_document
date: "2024-01-15"
---

```{r cars}
library(gt)
bob <- "carb"
gt(mtcars) |>
  cols_label(contains(bob)~bob)
```

It seems there is an issue in Posit Connect. Has anyone of you already open a ticket to RStudio Support ? If you have access to Connect you should have a customer service support and you can open an issue officially.

I'll pass along internally also.

Ok so Posit Connect renders using a new environment and the error can be reproduced locally now too

rmarkdown::render("index.Rmd", envir = new.env())

So this is not linked to Posit Connect at all. Just something with gt and how code is evaluated in R Markdown context.

I will keep looking

Good, we are at the same place. I was down to tidyeval. It makes senses that the new.env() does not have access to variable defined in the global environment.

The only issue is that this not obvious for the end user, but it makes sense in the R environment context.

Still something wonky going on I believe.

I think it is more complexe that that. The variable bob should not be in the global environment, as render() is passed with envir = new.env(). This should mean that knitting will happen in this environment I believe.

I can't reproduce issue with dplyr or other - only gt. So possibly something related to how this is working inside gt itself. We'll see

Hey @cderv does that include the pointblank example I shared as well? I can try later myself when I get on a computer

Confirming I can also reproduce the pointblank example shared earlier