Missing package name in not installed error

[malcolmbarrett]

Prework

• I have read and understand help guide.
• I understand and agree to contributing guide.
• I am confident this issue is a bug in targets itself, not a user error or a bug in a different package. I have done troubleshooting on my own to verify this. User questions which are not bugs in targets should be posted as discussions instead of bug reports.
• I am posting a runnable reprex to help others troubleshoot.

Description

Not installed errors emerging from rlang::check_installed() are not being correctly assembled by targets.

reprex

# _targets.R
library(targets)

call_pkg <- function() {
  rlang::check_installed("fake.package")
}

list(
  tar_target(call, call_pkg())
)

I expect:

> tar_make()
+ call dispatched
✖ call errored
✖ errored pipeline [99ms, 0 completed, 0 skipped]
Error:
! The packages "fake.package" are required.

Or better yet The package "fake.package" is required.

Instead, I get an empty string for the package name:

> tar_make()
+ call dispatched
✖ call errored
✖ errored pipeline [99ms, 0 completed, 0 skipped]
Error:
! The packages "" are required.

[wlandau]

This is an odd special case caused by #997. #997 is when targets began forwarding custom error classes to the user. The problem is that rlang::check_installed() generates a special error class that has its own custom message that relies on data internal to the original condition object.

tryCatch(
  {
    options(rlang_interactive = FALSE)
    rlang::check_installed("fake.package")
  },
  error = function(condition) class(condition)
)
#> [1] "rlib_error_package_not_found" "rlang_error"                  "error"                       
#> [4] "condition"   

If you use that error class manually, as targets tries to do, then your intended error message gets ignored:

rlang::abort(message= "custom message", class = "rlib_error_package_not_found")
#> Error:
#> ! The packages "" are required.

In hindsight, #997 is not a good feature because it causes unpredictable edge cases like #1354 and #1484. targets needs to manually check the error class for problems like these. But it's too late to go back and remove #997. I'll see if I can improve the checks.

[wlandau]

Unfortunately "rlib_error_package_not_found" is its own isolated special case that needs to be handled manually.

[malcolmbarrett]

Thanks for the fast fix!