tar_stan_mcmc can't find stan_file object

[sakrejda]

This is a usage question, but in a bigger workflow I used tar_stan_mcmc with a .stan file that I copy into place during the pipeline run. The prep is handled by a target that outputs the file path but since tar_stan_mcmc checks whether stan_files is a character vector the check fails b/c it doesn't know about this object...

The target:

tar_stan_mcmc(
    name = simple_time_to_event_movement,                                  
    stan_files = {simple_time_to_event_build_file},        
    stdout = workflow::build_file("cmdstanr", fs::file_name(simple_time_to_event_build_file), "stdout.txt
    stderr = workflow::build_file("cmdstanr", fs::file_name(simple_time_to_event_build_file), "stderr.txt
    save_latent_dynamics = TRUE,                                    
    output_dir = workflow::build_dir("cmdstanr", "output", fs::file_name(simple_time_to_event_build_file)
    save_warmup = TRUE,                           
    inc_warmup = TRUE,        
    refresh = 1,                            
    data = model_A_event_data                 
  )    

The error message:

> targets::tar_make()
Error in assert_chr(stan_files) : 
  object 'simple_time_to_event_build_file' not found
Error: callr subprocess failed: object 'simple_time_to_event_build_file' not found
Visit https://books.ropensci.org/targets/debugging.html for debugging advice.

Is there a way to defer the evaluation of tar_stan_mcmc until this can happen correctly or am I just outside of the stantargets use case here?

[wlandau]

I think this is out of scope, especially given the decision from ropensci/software-review#430 to impose additional checks on the Stan file before the pipeline begins. I recommend generating those Stan files beforehand if you can. Alternatively, tarchetypes::tar_eval() has some metaprogramming capabilities to help with target specification, and this might you to substitute a Stan file name if you generate it during _targets.R: https://books.ropensci.org/targets/static.html#metaprogramming.

This issue actually came up in #12 because brms programmatically generates Stan files tailored to the input data. I have not had time yet to explore a potential brmstargets package, but in any case, that's the sort of thing I think would require a new set of target factories if we want to make it easy for users.

[sakrejda]

Thanks!