A way to manually force specific targets to be regarded as up-to-date?

[koefoeden]

Hi!

Does anyone know of a way to manually force a specific target to be regarded as up-to-date, and thus skipped, on the next tar_make()-prcoess? Kind of like tar_invalidate(), but inversed?

For context, it happens quite often that I need to make changes to targets which shouldn't need to invalidate already computed targets, such as adjusting number of allocated CPU cores. Similarly, I run my pipeline on several nearly-identical datasets using tar_map, which sometimes needs to handle new edge-cases/peculiarities of that specific dataset, which shouldn't affect the other datasets.

I have experiemented with temporary tar_cue("never")-arguments in the specific targets after having changed the code (potentially using tar_invalidate() on the branches that actually needs updating), but it seems that all targets re-run after removing the tar_cue() again.

I realize it could introduce a lot of problems if used recklessly, but I think it would be quite powerful and time-saving to have!

[wlandau]

Cues are designed for this situation, and targets hesitates to provide more flexibility because of concerns about reproducibility.

number of allocated CPU cores

You set a custom environment variable to control the number of cores for your custom code.

[koefoeden]

Thanks for the reply! Could you elaborate a bit on how you would use the tar_cue() in this situation, besides my mentioned experiments with adding tar_cue("never") temporarily and removing it afterwards? Or perhaps this approach should actually work, and I somehow botched it somewhere?

Regarding the allocated CPU cores, I just used this as an example of where you might add some extra code that you know shouldn't affect the final output of the target - I do indeed manage such settings in a better fashion!

[koefoeden]

Or are you suggesting to simply keep tar_cue(command=FALSE) on as long as the command of a target is likely to undergo changes, and then manually invalidating it when needed? And perhaps setting it to the default "thorough" value when it has stabilized more?

[koefoeden]

Or are you suggesting to simply keep tar_cue(command=FALSE)

I realize I the correct arugment is likely depend=FALSE here, as validation by user-defined functions in the command is covered by this argument, instead of command=FALSE, as explained in the documentation for tar_cue(). However, it might be valuable to being able to distinguish between validation from user-defined functions, and upstream targets, if possible, adding a little bit of extra granularity?