Can we use progressr within targets framework?

[agila5]

Dear all, I've decided to create this discussion since I have a (maybe silly) question: is it possible to use the progressr package within the targets framework? For example, when I run the following code on my Rstudio session I see the expected progress bar:

library(progressr)
with_progress(slow_sum(1:10, message = FALSE))

However, I don't see anything when I run the following:

library(targets)
library(progressr)
tar_dir({
  tar_script({
    tar_option_set(packages = "progressr")
    list(tar_target(slow, with_progress(slow_sum(1:10, message = FALSE))))
  }, ask = FALSE)
  tar_make()
})

Am I doing something wrong? Is that known/expected? Is there any possible workaround? Thanks for your assistance!

[HenrikBengtsson]

I just tried with the global progression handler, instead of with_progress(), but it made no difference;

library(targets)
library(progressr)
handlers(global = TRUE)
handlers("debug")  ## give details on all progression conditions received

tar_dir({
  tar_script({
    tar_option_set(packages = "progressr")
    list(tar_target(slow, slow_sum(1:10, message = FALSE)))
  }, ask = FALSE)
  tar_make()
})

@wlandau, any comments? I don't know how targets handles conditions or a random class. Are they silently swallowed, or relayed? The progressr package signals conditions of class c("progression", "immediateCondition", "condition"), and the global calling handler, set by handlers(global = TRUE), will listen to progression conditions and handle them. From the example, it looks like they never end up at the global calling handlers.

[agila5]

Actually, I just found a discussion (ropensci/targets#661) where @wlandau explains that the integration of targets and progressr may be tricky and out of scope 😭

[HenrikBengtsson]

I just added a comment to that discussion.

[agila5]

Thanks!

[wlandau]

When you call tar_make(), the following happens:

1. A reproducible callr::r() process beings.
2. The process runs the _targets.R to populate the environment of the pipeline and get the target list.
3. The targets in the pipeline run.

So all the configuration of the progress bar needs to be inside tar_script() which writes the _targets.R file for the example. And in the case of parallel workers, the progress bar setup needs to be inside the command of the target that uses it.

In real life usage of targets, you would create _targets.R with use_targets() and then write in the progressr integration by hand instead of using tar_dir() or tar_script().

The following example works on my end.

# _targets.R file:
library(targets)
tar_option_set(packages = "progressr")
list(
  tar_target(
    slow, {
      handlers("debug")
      slow_sum(1:10)
    }
  )
)

# R console:
tar_make()
#> • start target slow
#> M: Added value 1
#> M: Added value 2
#> M: Added value 3
#> M: Added value 4
#> M: Added value 5
#> M: Added value 6
#> M: Added value 7
#> M: Added value 8
#> M: Added value 9
#> M: Added value 10
#> • built target slow [10.128 seconds]
#> • end pipeline [10.208 seconds]

[agila5]

Hi @wlandau and thanks for your reply.

Maybe I'm missing something, but I think that the "M: Added value xyz" output is just given by a call to message() inside slow_sum:

https://github.com/HenrikBengtsson/progressr/blob/26503ca732d7f191358db6d759cef3258320ce9d/R/slow_sum.R#L40-L42

and not actually related to any progressr code. For example, if I run the following code in a regular R session

library(progressr)
handlers("debug")
with_progress(slow_sum(1:1, message = FALSE))

on the console I see

> with_progress(slow_sum(1:1, message = FALSE))
[16:45:21.650] (0.000s => +0.000s) initiate: 0/1 (+0) '' {clear=TRUE, enabled=TRUE, status=}
[16:45:21.650] (0.000s => +0.000s) update: 0/1 (+0) '' {clear=TRUE, enabled=TRUE, status=}
[16:45:22.051] (0.401s => +0.000s) update: 0/1 (+0) '' {clear=TRUE, enabled=TRUE, status=}
[16:45:22.253] (0.603s => +0.001s) update: 1/1 (+1) 'P: Adding 1' {clear=TRUE, enabled=TRUE, status=}
[16:45:22.253] (0.603s => +0.001s) update: 1/1 (+0) 'P: Adding 1' {clear=TRUE, enabled=TRUE, status=}

If I run a similar code using an auxiliary _targets.R file

# _targets.R file:
library(targets)
tar_option_set(packages = "progressr")
list(
  tar_target(
    slow, {
      handlers("debug")
      with_progress(slow_sum(1:1, message = FALSE))
    }
  )
)

the console says

• start target slow
• built target slow [1.012 seconds]
• end pipeline [1.086 seconds]

without any additional output.

Anyway, thank you very much for your assistance.

EDIT: I just noticed that the discussion continued on the other thread, sorry...

[HenrikBengtsson]

Just to clarify, those M: Added value ... messages originate from the slow_sum(1:10) call. What is not shown in the output here, is that targets outputs those momentarily as they are produced, meaning you see incremental output. (That's really nice).

The progressr handlers("debug") is not outputting anything in this example, because there's nothing listening to progress conditions. For that to work, one could do:

# _targets.R
library(targets)
tar_option_set(packages = "progressr")
list(
  tar_target(
    slow, {
      options(progressr.enable = TRUE) # because non-interactive
      handlers("progress")
      with_progress(slow_sum(1:10))
    }
  )
)

which will produce the following output as it appears:

> targets::tar_make()
• start target slow
M: Added value 1                                                              
M: Added value 2                                                              
M: Added value 3                                                              
\ [================>----------------------------------------]  30% P: Adding 3

Nice.

[agila5]

Thanks for your reply! Could you share an example where the progress bar displays a series of updates when it is included into a future_lapply() call? I tried to replicate the example showed here inside a targets workflow, but without any success.