It looks like sourceWithProgress() creates a fresh clean environment in which to source the R script, which seems like a good idea. However, what if the script itself sources other scripts? By default, the child scripts will use the global environment, not the environment that sources the parent script:
I believe this might be affecting
opened 03:40PM - 29 Mar 19 UTC
closed 08:01PM - 29 Mar 19 UTC
type: use case
## Prework
- [x] Read and abide by `drake`'s [code of conduct](https://github… .com/ropensci/drake/blob/master/CODE_OF_CONDUCT.md).
- [x] Search for duplicates among the [existing issues](https://github.com/ropensci/drake/issues), both open and closed.
## Description
I have a drake workflow with a long-running step and in my pre-drake life I would use the RStudio Job Launcher to run these kinds of tasks in the background so I can keep coding in my console.
I've discovered, though, that without additional work, running `drake::make()` as an RStudio background job invalidates targets that depend on functions sourced into the global environment. Running `drake::make()` or `drake::r_make()` from a standard environment _after_ running `make()` inside the RStudio job launcher will again invalidate old but up-to-date targets, including those just built by the job launcher.
It took me quite a bit of poking around to be able to pare down the problem to the [reproducible example in this repo](https://github.com/gadenbuie/drake-rstudio-jobs-example#readme), but in doing so I think I've uncovered that the invalidating results from some minor changes to the global environment that RStudio uses to monitor script progress and update the job viewer.
A side-effect of this is that all of the hashes in the cache log are the same between steps, so it's not immediately obvious _why_ the targets are invalidating. Some digging with `deps_profile()` eventually provide clues that something is amiss. In the end, using an environment for the function dependencies clears up the problem.
I'm sharing here because I thought you might like to know and to find out if I'm doing anything very wrong in [my setup](https://github.com/gadenbuie/drake-rstudio-jobs-example#readme). I'm not sure if there's anything you can or would want to do about this, other than to document the issue, and with RStudio 1.2 releasing soon (or eventually) I would imagine that other drake users will try to do what I did and be equally confused. Also, if the workflow and solution in my reprex repo seems reasonable, I'll wrap it up into a blog post.
and
1 Like
Would you mind filing this as a bug report at https://github.com/rstudio/rstudio/issues ? It sounds like this is indeed something we should attempt to properly handle.
1 Like
Sure, I just submitted one here .
1 Like
system
April 26, 2019, 6:53pm
4
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.