Should global objects with external dependencies be functions?

[djbirke]

Question

If a global object depends on an external package, should it be wrapped by a function?

For example, how do I incorporate a ggplot template into targets? Do I explicitly name the package (version 1) or wrap the list of plot components by a function (version 2), so that targets can figure out the dependency?

A third alternative is to load all dependencies at the top (version 3), but this loses the speed advantage described in the user manual.

Version 1

library(targets)

common_coord <- list(ggplot2::coord_cartesian(xlim = c(1, 3)))

plot_vs_hp <- function(df) {
  df %>%
    ggplot(aes(x = wt, y = hp)) +
    geom_point() +
    common_coord
}

plot_vs_mpg <- function(df) {
  df %>%
    ggplot(aes(x = wt, y = mpg)) +
    geom_point() +
    common_coord
}

tar_option_set(packages = "tidyverse")

list(
  tar_target(p_hp, plot_vs_hp(mtcars)),
  tar_target(p_mpg, plot_vs_mpg(mtcars))
)

Version 2

# Version 2
library(targets)

common_coord <- function() {
  list(coord_cartesian(xlim = c(1, 3)))
}

plot_vs_hp <- function(df) {
  df %>%
    ggplot(aes(x = wt, y = hp)) +
    geom_point() +
    common_coord()
}

plot_vs_mpg <- function(df) {
  df %>%
    ggplot(aes(x = wt, y = mpg)) +
    geom_point() +
    common_coord()
}

tar_option_set(packages = "tidyverse")

list(
  tar_target(p_hp, plot_vs_hp(mtcars)),
  tar_target(p_mpg, plot_vs_mpg(mtcars))
)

Version 3

# Version 3
library(targets)
library(tidyverse)
common_coord <- list(coord_cartesian(xlim = c(1, 3)))

plot_vs_hp <- function(df) {
  df %>%
    ggplot(aes(x = wt, y = hp)) +
    geom_point() +
    common_coord
}

plot_vs_mpg <- function(df) {
  df %>%
    ggplot(aes(x = wt, y = mpg)) +
    geom_point() +
    common_coord
}

tar_option_set(packages = "tidyverse")

list(
  tar_target(p_hp, plot_vs_hp(mtcars)),
  tar_target(p_mpg, plot_vs_mpg(mtcars))
)

[wlandau]

Good question. Unless the object has brittle metadata (e.g. ropensci/drake#345) or system-dependent external pointers, I would recommend tracking the object as a global variable. That way, if you update the package where the object really lives, targets will invalidate the object and the appropriate downstream targets. If you wrap the object in a function, then targets will track the deparsed code to generate the object instead of the object itself. That means unless you call tar_option_set(imports = "ggplot2") (which seems cumbersome for your use case) updating the package will not invalidate the object.

[djbirke]

Thank you for the quick answer. I have two follow-up questions:

1. Why do you consider setting tar_option_set(packages = "tidyverse", imports = "tidyverse") as cumbersome in my use case? (It seems like a small change at one line of code to me. I do see that version 2 adds more lines/characters from wrapping objects into functions and calling them later. Is that what you refer to?)
2. Did I understand correctly that the difference between versions 1 and 3 is that version 3 would load tidyverse even when skipping all targets, whereas version 1 only loads packages if necessary to run a target?

[wlandau]

1. The imports option tracks everything in a package, even internals. Easy to write, but it imports a lot of objects.
2. Version (1) is slightly better than (3) because, as you say, library(tidyverse) is slow and would run when skipping targets and in other functions like tar_outdated().

[djbirke]

Thank you for the additional explanation.