Is there a way to get sessionInfo() for all packages used?

[billdenney]

I'm starting to really get into targets, and I really like its design and implementation!

Question: Is there a built-in way to get complete sessionInfo() for all targets?

Thoughts:
I often use targets (and previously used drake) to generate reports built upon time-intensive analysis. To enhance reproducibility, I always put the sessionInfo() at the bottom of the report. With drake, since all packages were always loaded, sessionInfo() reported all of the packages. One thing that I like about targets is that I can load packages specifically for one target but not for others. That helps a lot with preventing function name collisions. But with targets, I don't see a way to get a complete sessionInfo().

I could imagine doing something like creating a new targetopia target-generator that would do something like create a new name_session target with the sole purpose of collecting the sessionInfo(), but before going down that route, I wanted to see if I were missing something where I could get the sessionInfo() for all targets through an existing mechanism.

Below is an example of how, as expected, nlme does not show up in the sessionInfo().

library(targets)
#> Warning: package 'targets' was built under R version 4.1.1
tar_script(
  list(
    tar_target(
      model,
      lme(distance ~ age, data = Orthodont),
      packages="nlme"
    ),
    tar_target(
      session,
      sessionInfo()
    )
  )
)
tar_make()
#> * start target session
#> * built target session
#> * start target model
#> * built target model
#> * end pipeline
#> Warning messages:
#> 1: package 'targets' was built under R version 4.1.1 
#> 2: package 'nlme' was built under R version 4.1.1 
#> 3: 1 targets produced warnings. Run tar_meta(fields = warnings) for the messages. 
tar_read(session)
#> R version 4.1.0 (2021-05-18)
#> Platform: x86_64-w64-mingw32/x64 (64-bit)
#> Running under: Windows 10 x64 (build 19043)
#> 
#> Matrix products: default
#> 
#> locale:
#> [1] LC_COLLATE=English_United States.1252 
#> [2] LC_CTYPE=English_United States.1252   
#> [3] LC_MONETARY=English_United States.1252
#> [4] LC_NUMERIC=C                          
#> [5] LC_TIME=English_United States.1252    
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> other attached packages:
#> [1] targets_0.7.0
#> 
#> loaded via a namespace (and not attached):
#>  [1] igraph_1.2.6      rstudioapi_0.13   knitr_1.34        magrittr_2.0.1   
#>  [5] tidyselect_1.1.1  R6_2.5.1          rlang_0.4.11      fansi_0.5.0      
#>  [9] tools_4.1.0       data.table_1.14.0 xfun_0.25         utf8_1.2.2       
#> [13] cli_3.0.1         withr_2.4.2       ellipsis_0.3.2    yaml_2.2.1       
#> [17] digest_0.6.27     tibble_3.1.4      lifecycle_1.0.0   crayon_1.4.1     
#> [21] processx_3.5.2    purrr_0.3.4       callr_3.7.0       vctrs_0.3.8      
#> [25] ps_1.6.0          codetools_0.2-18  glue_1.4.2        compiler_4.1.0   
#> [29] pillar_1.6.2      pkgconfig_2.0.3

^{Created on 2021-10-27 by the reprex package (v2.0.1)}

[wlandau]

I see what you are saying, though I do not have plans to build anything special for this. One idea is to have an R Markdown that sources the script produced by tar_renv() (possibly calling tar_renv() to produce that script to begin with) and calls sessionInfo(). You could run such an R Markdown outside the pipeline or as a downstream tarchetypes::tar_render() target.

[billdenney]

Thanks for the info. I didn't think that it would be a good fit for the base targets package (or likely tarchetypes, though, once written, I may ask if it seems to be a good fit there-- a discussion for another day).

Thanks for the tar_renv() pointer. That does look like it would give most if not all of what I'm looking for.

I have another thought that could possibly be of general interest for targets: Is there any way to hook into the R sessions that are spawned for each target? What I'm thinking is that for this particular use case, a hook that occurred after the result were saved back to the object store could be of interest. (I see that hooks like this could get too complex with too few use cases-- making targets code harder to develop and support.)

For the hooks, the way that I'd like it to look would be something like (I'm guessing that this is how targets works under the hood to some degree):

1. Load the required libraries
2. Run the scripts holding the functions to run
3. Load the function arguments
4. Run the function with its arguments
5. Save the result

And, I'm thinking that having a hook at one or more of the spots here could enable some deeper modifications. For this example, if there were a possibility to have a step 5b with a hook, I could run and save the sessionInfo() which would theoretically allow the report to get more granular on the reproducibility (e.g. "The model XXX was fit with the following libraries loaded: ...").

[wlandau]

I do not plan to support this definition of hooks because I would be concerned about encapsulation and reproducibility. A primary goal of targets is to enforce guardrails that protect users, and this goal conflicts with the arbitrary flexibility proposed in #676 (comment). If a target needs to do something, it should be written in the target's command.

That said, tarchetypes does have its own ideas about hooks: https://docs.ropensci.org/tarchetypes/reference/index.html#section-hooks. tarchetypes let you statically insert code into entire batches of target commands programmatically. Because the targets' commands are the only things that get modified, this approach does not break any abstractions, and it is idiomatic.

[billdenney]

Not supporting the above definition of hooks makes sense. Thanks for the pointer to tar_hook_*(). I think that would cover the need. I think that I now have what I need to use for making the session-saver that I want.

Thank you as always for your good work and your quick answers!