Is it possible to ignore parts or all of a domain specific language?

[billdenney]

This is related to #701 and the same as the drake issue in ropensci/drake#910.

We had previously discussed this issue for drake. As I'm working on an identical model with targets, I'm having the identical issue. In drake, I would have used ignore(), but I don't see something equivalent in targets. Is there a way to tell targets to ignore something for parsing like drake could?

The real example uses the nlmixr2 library, but identity() illustrates the reprex.

library(targets)
#> Warning: package 'targets' was built under R version 4.1.3
tar_script({
    library(targets)
    model <- function() {
        ini({
            x1 <- 1
        })
        model({
            x2(0) <- x3
            d/dt(x2) <- 1
            x2 ~ add(x1)
        })
    }
    list(tar_target(my_model, identity(model)))
})
tar_make()
#> Error : bad assignment: 'x2(0) <- x3'
#> In addition: Warning message:
#> package 'targets' was built under R version 4.1.3 
#> Error in `tar_throw_run()`:
#> ! callr subprocess failed: bad assignment: 'x2(0) <- x3'
#> Visit https://books.ropensci.org/targets/debugging.html for debugging advice.

^{Created on 2022-07-15 by the reprex package (v2.0.1)}

[wlandau]

You could enclose the function definition in evalq() or eval(quote()). {targets} uses code tools::findGlobals() (mostly).

[billdenney]

Thanks for tracking down the issue. Is there any way that a targets package (ala nlmixr2targets) could somehow selectively override the parsing within codetools::findGlobals()?

One thing that I could imagine is that findGlobals() could be made to be generic, and *targets packages (like nlmixr2targets) could then make custom functions that would specifically update the parsing for findGlobals().

Or perhaps another option would be to allow a target to selectively turn off findGlobals() for specific elements within the namespace. Something like codetools::noGlobals(model) could be run on the initial example above?

I agree that custom code analysis within codetools/targets seems like a bridge too far.

[wlandau]

That interface-level piece would still require a whole custom code system underneath.

[billdenney]

I've been thinking overnight about how to fix this. Unfortunately, I don't think that the eval(parse(text = "x2(0) <- x3")) solution will work because the way that nlmixr2 interacts with the function is by working with the parsed R object, but the function itself is never run.

I see two ways that may get the same result. I think that the overall goal would be to hide assignments that look like they are modifying 0 from targets. To accomplish that, I the solutions I am thinking of look like about the same thing:

• Modify the DSL itself. Make something like x2[0] <- x3 replace x2(0) <- x3 (square brackets instead of parentheses). That is valid R (which results in a zero-length vector when assigned). This is clear that it would work, but it would likely be a heavy lift. This would also require the next solution because we would keep the x2(0) <- x3 syntax for backward compatibility.
• Make nlmixr2targets act as though it is modifying the DSL. Choose something that would look like normal R (e.g. initial(x2) <- x3) and replace all the values that would be these parse errors with that new code during the target setup in the actual global object. Then, switch it back to the normal DSL syntax within the function that uses the object. (If the first solution was used in conjunction, then the back-transform would not be required; it would just make the switch to the targets-friendly syntax and leave it there.)

Before diving into these as solutions, do you think that they would work? Specifically, when in the process does codetools::findGlobals() do its work, and is it possible to modify the objects in the global namespace before that time to work around this issue?

[billdenney]

One more idea just occurred to me. I believe that targets does not search for globals within package namespaces. Would it be possible to move the DSL function into something like a package namespace so that findGlobals() would ignore it?

[wlandau]

Before diving into these as solutions, do you think that they would work? Specifically, when in the process does codetools::findGlobals() do its work, and is it possible to modify the objects in the global namespace before that time to work around this issue?

targets uses codetools::findGlobals() for detecting the upstream dependencies (targets and objects) of a target or function. In other words, to build the dependency graph.

One more idea just occurred to me. I believe that targets does not search for globals within package namespaces. Would it be possible to move the DSL function into something like a package namespace so that findGlobals() would ignore it?

Yeah, that should work if the package is not in tar_option_get("imports"). In fact, for each function that uses the nlmixr DSL, you could wrap it in a list or environment so targets does not think it's a function. Or better yet, wrap just the DSL blocks and call them inside R functions (so the dependency graph includes legitimate globals that the function depends on).