Rprofile, callr, and setting options – compatibility with box

[pvtodorov]

I'm trying to use targets with the box package.

I have the following code in my .Rprofile that sets a box.path telling the box package where to look for modules and scripts.

options(box.path = paste0(Sys.getenv("PROJECT_DIR"), '/code'))

This works in interactive sessions and I can load modules and scripts with box without an issues.

When I attempt to use targets::tar_vistnetwork() I get an error related to callr, which I've described here. I can solve this by calling the same options code above my box imports in my _targets.R script.

I'm not sure I understand how targets works at this level. Is it not sourcing the .Rprofile? Is there a way to get it do so? I would appreciate any guidance and help in understanding!

[wlandau]

tar_make() works by staring a callr process which sources _targets.R and then running the pipeline. Likewise for tar_visnework() except that it gives you a graph. For testing purposes, you can avoid the callr process by setting callr_function = NULL, but it risks incorrectly invalidating some targets, so I only recommend it for debugging and testing.

I can solve this by calling the same options code above my box imports in my _targets.R script.

Yeah, that's good practice.

[pvtodorov]

This makes sense, however, I already have the box.path set in my .Rprofile. I'm not sure I understand why I need to set it again in the _targets.R script.

[pvtodorov]

Thanks for the quick reply! I appreciate it and have been enjoying the utility targets brings to my projects.

I suppose I am running into some additional friction trying to use @klmr's box package to manage my local code more explicitly instead of using source() to load a bunch of R scripts into the global namespace.

Here are some minimal examples

Example 1

I have a _targets.R file where I'm attempting to manage all my imports with box.

options(box.path = '/projects/petar/fgf1/code/')


box::use(targets[tar_option_set,
                 tar_target],
         blah/add_some_number[add_two,
                              add_four])

# Replace the target list below with your own:
list(
  tar_target(two_added, add_two(2)),
  tar_target(four_added, add_four(2))
)

The box.path points at a file add_some_number.R with the following contents:

box::export(add_some_number, add_another_number)

add_two = function(input_number){
    output_number = input_number + 2
    output_number
}


add_four = function(input_number){
    output_number = input_number + 4
    output_number
}

targets::tar_visnetwork() produces an output that does not show the functions loaded by box.

I can actually run targets::tar_make() successfully. Both objects show up as "Up to date". When reading out the result from two_added I get 4 and four_added I get 6.

Example 2

I've tried using box differently. Instead of importing functions, I import the whole module and call the functions from the imported module object using the $ operator. In this case _targets.R looks like this

options(box.path = '/projects/petar/fgf1/code/')


box::use(targets[tar_option_set,
                 tar_target],
         blah/add_some_number)

# add_some_number = add_some_number
# add_another_number = add_another_number

# Replace the target list below with your own:
list(
  tar_target(two_added, add_some_number$add_two(2)),
  tar_target(four_added, add_some_number$add_four(2))
)

Everything executes sucessfully and the module is tracked by targets.

But if I make changes to either function within add_some_number.R both targets become Outdated. I pretty much expected this to happen anyway since targets is tracking the module itself.

Example 3

I noticed that if I set the functions exported by box equal to themselves as in add_two = add_two they are now tracked by targets.

options(box.path = '/projects/petar/fgf1/code/')


box::use(targets[tar_option_set,
                 tar_target],
         blah/add_some_number[add_two,
                              add_four])

add_two = add_two
add_four = add_four

# Replace the target list below with your own:
list(
  tar_target(two_added, add_two(2)),
  tar_target(four_added, add_four(2))
)

Calling tar_make() works

Changes made to a single function are sucessfully tracked without making the target of the unchanged function out of date.

Although this works, the code style is very strange and inconvenient.

I am trying to figure out:

• What is the difference between using these functions in an interactive session vs within _targets.R?
• Why are the functions not tracked in the case of Example 1?
• Is there a practical solution to this?

[wlandau]

targets looks for functions and other global objects in the environment returned by tar_option_get("envir"), which is usually the global environment. You can change this environment with tar_option_set() in _targets.R, or you could supply the tar_option_get("envir") environment to box.

[nikitautiu]

I was curios if there is a solution for this nowadays. The expected behaviour of box as you do in examples 1 and 3 is to attach the functions to the global environemnt. However, having tar_options_set(envir = globalenv()) at the top of _targets.R and then invoking box::use(module[f]) does not end up tracking f as an object in the graph.

[motorlearner]

The expected behaviour of box as you do in examples 1 and 3 is to attach the functions to the global environemnt.

As far as I can tell that is not true. box::use(module) will attach "module" to the global env, but box::use(module[f]) will create a module environment "mod:module" which contains f.

Whatever is attached to the global env seems to be tracked by targets (hence Examples 2 and 3 above).

targets also has an option to track packages via tar_set_option(imports = ...) which is intended for user-written packages...but (besides some problems with calling tar_visnetwork if you try using that on an R package) this is also not compatible with box modules.

[pvtodorov]

Some additional experiments with setting box.path in .Rprofile, .Renviron, and _targets.R by using Sys.setenv() or option() which produce slightly different results. I am curious about what goes on behind the scenes and why to produce these different behaviors.

[zackarno]

Hi, I was curious if this discussion has lead to a recommended way to use {box} with {targets}?

I noticed that Section 7.1 of The {targets} R package user manual states:

"Some package management workflows are more complicated. If your use special configuration with conflicted, box, import, or similar utility, please do your configuration inside a project-level .Rprofile file instead of the target script file"

Based on the above, I thought there might be an example of the recommended way to do this somewhere?

Is it just option 3 from @pvtodorov additional experiments ?

setting it as Sys.setenv(R_BOX_PATH = '/projects/petar/fgf1/code/') in the .Rprofile works

So would code/ just be the directory where box modules are stored inside the r project directory?

Thanks so much! it would be very exciting and useful to get {box} working in {targets}

[motorlearner]

Examples 2 and 3 both add something to the global environment, which is then tracked.

For now, I am using a function to do Example 3 from above, i.e. adding each loaded function to the gobal env. Although if you do that, you might as well just source those files. Also curious if there is a real solution.

# assumes all functions are in ./funcs/R
mods_to_globalenv <- function() {
  box::use(stringr[ str_subset ], rlang[ search_env, env_names, env_get, global_env ])
  mods <- str_subset(search(), "mod:funcs/R")
  for (envname in mods) {
    env <- search_env(envname)
    for (fname in env_names(env)) {
      f <- env_get(env, fname)
      assign(fname, f, envir = global_env())
    }
  }
}