Closed matthiasgomolka closed 3 years ago
I regret cache flexibility in drake
because it causes room for too much room for ambiguity and dangerous careless errors that cause loss of hard-earned data. For a tool that tries to promote reproducibility, this is especially egregious. I try to elaborate on this at https://github.com/ropensci/targets/discussions/297. targets
is similar here because drake:r_make()
works just like targets::tar_make()
and is recommended over regular make()
.
Thanks for the explanation. I understand your reasoning, but I don't see how I can apply this strict view to my situation at work.
Would it be OK to open a "Help"-Issue in the targets GitHub repo?
Sure, feel free to post a discussion thread to targets
.
Prework
drake
's code of conduct.Proposal
In our team we use drake with a non-default cache directory. This works fine, but it would be a little more convenient if we could easily pass the non-default path to all drake functions which use the arguments
cache
andpath
(such asreadd()
orloadd()
). This could be done easily if the default value forpath
would be changed togetOption(drake.path_cache)
.Then, one could set this option and all drake functions which use the cache would work without specifying
path = "/path/to/cache"
orcache = non_default_cache
.Current behaviour
Proposed behaviour
This would work because the default value for
cache
isdrake::drake_cache(path = path)
. So the changes are minimal and the default behaviour would not change sincegetOption(drake.path_cache)
defaults toNULL
(the current default forpath
) if the optiondrake.path_chache
is not set.Of course, the name of the option is just a suggestion.
What do you think?
BTW: Due to drake, many of my colleages now make the switch to using R. So, again, thanks for your efforts!