Rich FitzJohn

OSX too! This is probably not something that can be worked around directly, but something that should be documented. Something that could be dealt with in the #89 work?

Oh wow I have no idea. storr has made it to CRAN and it looks like the build is broken with what looks like storr errors so I guess this...

shorter: ``` > library(drake) > library(storr) > load_mtcars_example() > make(my_plan, verbose = FALSE) > cache1 cache1$get_hash("regression1_large", namespace = "kernels") [1] "e1501ed9d62b846e" > cache1$hash_object(cache1$get("regression1_large", namespace = "kernels")) [1] "378d49d1626bdd6f" ``` and...

It looks an awful lot like this is an environment serialisation issue ``` h regression1_small [3] reg1 ->regression1_large [4] reg2 ->regression2_small [5] reg2 ->regression2_large [6] "report.Rmd" ->report [7] coef_regression2_small->report [8]...

ah, the version number is just not there in the second cache for reasons that also look suspicious

I should take a look! :grinning: This is something I thought about a bit last year but never progressed. There are some issues here (for example, do key *names* also...

Thanks - I agree this seems unfortunate. I can look at expanding the boolean hook to support yes/no. The issue is you start getting a lot of really weird bugs...

Any thoughts on this @krlmlr?

So, the `yaml::yaml.load` function provides support for handlers which we use to avoid things like `t`, `f`, `n` and `y` being interpreted as logicals, but there is no corresponding easy...

For *generating* we are limited by the yaml package - this issue here is the relevant one: https://github.com/viking/r-yaml/issues/30