Accessing params from a sourced script when publishing

RStudio Connect does not seem to allow me to publish a parameterized RMarkdown that sources a script using the parameters. For example, I created the following test RMarkdown file:

---
title: "Parameter test"
params:
  min_date: !r as.Date('2017-12-26')
output: html_document
---
knitr::opts_chunk$set(echo = TRUE)
source("test_script.R")
## R Markdown

Print the filtered dataframe:

```{r}
dates_filtered

which relies on this script, called test_script.R:

library(tidyverse)

dates <- data.frame(date_vec = seq(as.Date('2017-01-01'), as.Date('2017-12-31'), by = 'days'))

dates_filtered <- dates %>% 
  filter(date_vec >= params$min_date)

I can knit the Rmarkdown just fine locally, but when I attempt to publish, I get the error:

[Connect] 2020/07/16 20:16:59.279274519 Quitting from lines 13-14 (test_script.Rmd) 
[Connect] 2020/07/16 20:16:59.315233580 Error: Problem with `filter()` input `..1`.
[Connect] 2020/07/16 20:16:59.315255817 ✖ object 'params' not found
[Connect] 2020/07/16 20:16:59.315288357 ℹ Input `..1` is `date_vec >= params$min_date`.

Any idea why Connect doesn't allow for this type of behavior, despite it working well locally?

In some contexts, resource files are the important bit here

https://docs.rstudio.com/connect/user/rmarkdown/#r-markdown-resource-files

However, I think your problem is that the params variable is not available in the context you are trying to use it in. I would add some debugging lines like print(capture.output(str(params))) or look at the options to source and whether it allows for setting the environment that your script is running in.

Generally for this type of "sub-script," I would recommend making the "child" document an R Markdown script and looking into rmarkdown::render() , because you have lots of controls over the environment that it is executed in, and can even pass parameters like rmarkdown::render(params = list(myparam = "something")).

Do you have this source stored somewhere on GitHub / etc. so that others could easily try it?

2 Likes

Adding local = TRUE as an option to source fixes the problem! When local = TRUE, the expressions in the script are evaluated in the environment from which source is called, so it can access the parameters. I created a GitHub repository for this code here: https://github.com/babichmorrowc/rsc_test, so you can see how the code looks.
As a side note, adding the following to the YAML does not solve the problem and is not nessary:

resource_files:
  - "test_script.R"
2 Likes

Woohoo!! Great sleuthing! And very glad to hear you figured it out :smiley: Well done!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.