Error in !deps$Dev when tar options set by a variable

[MarekGierlinski]

First minimal example. The following file is saved as _targets.R in the local directory.

library(targets)

tar_option_set(packages = c("cowplot", "tidyverse"), format = "qs")

renv:init() and renv::depencencies() work fine and discover required packages.

However, if the above file is re-written as

library(targets)

pkg <- c("cowplot", "tidyverse")
tar_option_set(packages = pkg, format = "qs")

then we have errors:

> renv::init()
* Initializing project ...
* Discovering package dependencies ... Error in if (package == "R") return() : 
  missing value where TRUE/FALSE needed
In addition: Warning message:
In eval(expr, envir = envir) : object 'pkg' not found
Traceback (most recent calls last):
5: renv::init()
4: hydrate(project = project, library = library)
3: renv_hydrate_dependencies(project, packages, sources)
2: renv_package_dependencies(packages, project = project, libpaths = libpaths)
1: renv_package_dependencies_impl(package, visited, libpaths, fields)

and

> renv::dependencies()
Finding R package dependencies ... Done!
Error in !deps$Dev : invalid argument type
In addition: Warning message:
In eval(expr, envir = envir) : object 'pkg' not found
Traceback (most recent calls last):
3: renv::dependencies()
2: deps[!deps$Dev, ]
1: `[.data.frame`(deps, !deps$Dev, )

I understand that the second error was reported before, under different circumstances.

[kevinushey]

Thanks for the bug report! The challenge with this:

pkg <- c("cowplot", "tidyverse")
tar_option_set(packages = pkg, format = "qs")

renv's dependency discovery algorithm is fairly primitive; in particular, it doesn't keep track of scopes or variable references, and so cannot figure out that pkg refers to some vector of packages.

[MarekGierlinski]

I guessed that much. But, I'd expect it to not discover these packages and simply ignore them. Instead, it crashes with a puzzling error. It took me quite a while of poking around to isolate the bug in my code.

[kevinushey]

That's absolutely true (and sorry for the trouble). That error should now be resolved in the development version of renv.