S4 classes and functions

[markpayneatwork]

Hi,

My pipeline uses an S4 class to store all the various configuration options necessary for the particular version of the analysis - each target in the pipeline gets this object as an argument. The entire pipeline can then be easily reconfigured for a different setup (e.g. data source etc)

The problem is that one of the slots in my S4 class is a function. Even though the source code is identical when I create the S4 object, the environment that is associated with the function can change from time to time. e.g.

where x and y are two different versions of the configuration object. Note the "environment" argument at the end - this is what is changing from time to time, and triggering (unnecessarily) the rest of the pipeline (I think!)

Is there anything I can do to get targets to ignore such minor changes?

[wlandau]

I recommend using a simpler data structure for configuration details, one that does not contain functions. Better yet, you could split these configuration details into different objects so not all targets rerun when one configuration element is changed. https://books.ropensci.org/targets/projects.html#multiple-projects could help manage multiple versions of a project.

Related: #887, ropensci/drake#345

[markpayneatwork]

Thanks for the tips. The targets package is growing faster than I can keep up with it - I swear I haven't seen the projects functionality before! :-) But that's a good thing.

[markpayneatwork]

Interestingly, the problem seems to go away when I use static branching (with branches generated via tar_map() and manual branch names) rather than dynamic branching (with automatically generated branch names). Might there be something there?

[wlandau]

Hard to say for sure, but maybe the object is no longer a runtime dependency of the actual targets if it is just used to create static branches. You can check tar_visnetwork() and see if it is disconnected in the graph.

[markpayneatwork]

That's correct - it's not connected in the graph. So, I think we have a workaround. Thanks!