Knitr called from RStudio does not preserve package loading order

Question

When I process Rmd markup files that used cached fragments in RStudio using the Knit HTML button, I found that the order in which packages were loaded was not remembered from piece to piece. This causes problems when I need to download packages in a specific order to avoid namespace conflicts.

For a reproducible example (for which you need to install the plyr, dplyr, and pryr packages, see below), I start by creating a knr Rmd document that loads plyr and then dplyr (which both exports the summarise function), then uses pryr to determine what summation function is found. I knit this using the RStudio "Knit HTML" button:

 ```{r} library(knitr) opts_chunk$set(cache = TRUE, message = FALSE) ``` ```{r test1} library(plyr) library(dplyr) ``` ```{r test2, dependson = "test1"} attr(pryr::where("summarise"), "name") ``` 

As recommended here , I load plyr before dplyr so that dplyr functions come first in the search path. As expected, the md output file shows that the summarise function comes from dplyr:

 attr(pryr::where("summarise"), "name") ## [1] "package:dplyr" 

However, if I make a small change in the test2 block:

 ```{r test2, dependson = "test1"} attr(pryr::where("summarise"), "name") # this is a change ``` 

which forces it to recompile, now it loads the packages in the wrong order, and summarise is in plyr:

 attr(pryr::where("summarise"), "name") # this is a change ## [1] "package:plyr" 

Please note that this problem does not occur if you run knit from the R command line, but this is only due to the fact that it stores the plyr and dplyr packages loaded into the environment (if I restart R, the same problem arises).

I know that I can reference functions like dplyr::summarise to avoid redundancy, but this is rather cumbersome. Not to download plyr is not an option at all, as several packages inadvertently add it to the namespace. How can I ensure that packages are downloaded in the correct order?

I am using the latest version of RStudio (0.98.1079) and my sessionInfo is below:

 ## R version 3.1.1 (2014-07-10) ## Platform: x86_64-apple-darwin13.1.0 (64-bit) ## ## locale: ## [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 ## ## attached base packages: ## [1] stats graphics grDevices utils datasets methods base ## ## other attached packages: ## [1] plyr_1.8.1 dplyr_0.3.0.2 knitr_1.7 ## ## loaded via a namespace (and not attached): ## [1] assertthat_0.1 codetools_0.2-8 DBI_0.3.0 digest_0.6.4 ## [5] evaluate_0.5.5 formatR_1.0 htmltools_0.2.4 magrittr_1.0.0 ## [9] parallel_3.1.1 pryr_0.1.0.9000 Rcpp_0.11.2 rmarkdown_0.3.10 ## [13] rstudioapi_0.1 stringr_0.6.2 tools_3.1.1 

Note that if necessary, you can configure the necessary packages for this reproducible example:

 ```{r} install.packages(c("devtools", "plyr", "dplyr")) devtools::install_github("hadley/pryr") ``` 

Answer 1

My retrieval request is to describe this problem while keeping the search order in the __packages file. Relevant Code:

 x = rev(.packages()) if (file.exists(path)) x = setdiff(c(readLines(path), x), .base.pkgs) writeLines(x, path) 

@Yihui combined the request of this commit , and it will most likely be available in knitr v1.8 in CRAN (or directly from GitHub or RForge).

Problems can still occur when packages are loaded into different pieces that are independent of each other, but this fixes the example in the question above and in other applications that I tried.

Answer 2

Conducting this as an answer, as it seems more relevant than commentary.

tl; dr : try removing cache/__packages manually between starts (and adding cache=FALSE to your batch package / running without caching packages) and see if this solves the problem ... or even add

 if (file.exists("cache/__packages")) unlink("cache/__packages") 

(I have not tested this with your example.)

I had a lot of problems with package caching, especially in working directories, where I run a lot of examples with optionally compatible sets of packages. I often just delete cache/__packages manually. I assume that the design can be improved (but I did not bother to build examples / think about how the design will be improved).