Plans as functions

[odgersn]

Prework

• Read and abide by drake's code of conduct.
• Search for duplicates among the existing issues, both open and closed.
• Consider instead posting to Stack Overflow under the drake-r-package tag.

Question

I'm trying to wrap my head around how best to implement plans as functions, with a view towards encapsulating these functions in a package. I know it's really pretty straightforward, but I guess I'd like confirmation about the "correct" way to handle how a function's arguments interact with the plan inside a function. The example functions that I have seen so far do not have arguments. Consider the following basic example:

library(drake)
library(raster)

pl_raster <- function(a, b) {
  drake_plan(
    r = raster(x = runif(!!a * !!b),
               nrows = !!a,
               ncols = !!b)
  )
}

pl_raster(5, 5)

# # A tibble: 1 x 2
#   target command                                       
#   <chr>  <expr>                                        
# 1 r      raster(x = runif(5 * 5), nrows = 5, ncols = 5)

Arguments a and b identify the number of rows and columns in the raster r, respectively. They're unquoted into the plan so that their values are substituted properly. I suppose that this is the "right" way to do it. It just seems like you could quickly accumulate a large number of arguments if you were functionising a large plan that has lots of inputs.

[wlandau]

I love this question, re: #994 and function oriented workflows.

Yes, this is exactly how I recommend encapsulating a plan inside a function. True, the function may accrue too many arguments if you are not careful, but I think this is a matter of defining the right priorities. What are the most important levers to tweak here? Personally, I find it particularly helpful to scale down / in for a test run and scale up / out for production. Maybe users of your package want to experiment with their own set of models. These are the arguments I would think about exposing.

Also, since you are developing a package with a plan, I recommend having a look at expose_imports() so that drake can detect the other functions in your package.

[odgersn]

Thanks Will. Just to be clear: I'd need to call expose_imports() before I call drake_config() or make() in the script that makes use of my package functions, correct? That's what ?expose_imports() seems to imply.

[wlandau]

Yes, exactly.