-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wildcards in trigger condition are not expanded #528
Comments
Wildcards in triggers
library(drake)
library(magrittr)
pkgconfig::set_config("drake::strings_in_dots" = "literals")
drake_plan(
a = n__ + 1,
b = target(
a_n__ + 2,
trigger=trigger(condition=a_n__ > 0)
)
) %>%
evaluate_plan(
rules = list(n__ = 1:2),
columns = c("command", "trigger")
)
#> # A tibble: 4 x 3
#> target command trigger
#> * <chr> <chr> <chr>
#> 1 a_1 1 + 1 <NA>
#> 2 a_2 2 + 1 <NA>
#> 3 b_1 a_1 + 2 trigger(condition = a_1 > 0)
#> 4 b_2 a_2 + 2 trigger(condition = a_2 > 0) The more general questionI like your workaround. When I designed triggers, I did not anticipate the need to explicitly suppress a target. Maybe there should be a |
Thanks! Totally missed |
No worries. |
Also, I tend to focus a lot more on the issue tracker than StackOverflow. I try to check the questions tagged with |
As far as I understand, one of the motivations for the new trigger interface (#473) was the ability to write a code like this:
This seems to work fine, however
evaluate_plan
seems to ignore trigger while expanding wildcards:That's the output:
I expected to have this:
A more general question
Please let me know if I should open a separate issue or ask on stackoverflow.
I would like to "kill" certain branches based on their input. E.g., if for some input data I haven't received enough results, I do not want to continue.
It seems that
trigger(condition=...)
won't help because dependency reasoning has a higher priority overcondition
andtrigger(depend=FALSE, condition=...)
will disable dependency monitoring for the target completely.The easiest workaround I see now is to return a special value (e.g.
NULL
). And in this case all downstream commands would have to check for a special value.Any suggestions?
The text was updated successfully, but these errors were encountered: