Difference: “Compile PDF” button in RStudio vs. knit() and knit2pdf()

First of all, I think this question is easier to answer if you limit the scope to the “Compile PDF” button, because the “Knit HTML” button is a different story. “Compile PDF” is only for Rnw documents (R + LaTeX, or think Sweave).

I’ll answer your question following the three points you suggested:

1. Currently RStudio always launch a new R session to compile Rnw documents, and first changes the working directory to the directory of the Rnw file. You can imagine the process as a shell script like this:

   cd path/to/your-Rnw-directory
   Rscript -e "library(knitr); knit('your.Rnw')"
   pdflatex your.tex
   

   Note that the knitr package is always attached, and pdflatex might be other LaTeX engines (depending on your RStudio configurations for Sweave documents, e.g., xelatex). If you want to replicate it in your current R session, you may rewrite the script in R:

   owd = setwd("path/to/your-Rnw-directory")
   system2("Rscript", c("-e", shQuote("library(knitr); knit('your.Rnw')"))
   system2("pdflatex", "your.tex")
   setwd(owd)
   

   which is not as simple as knitr::knit('path/to/your.Rnw'), in which case the working directory is not automatically changed, and everything is executed in the current R session (in the globalenv() by default).

2. Because the Rnw document is always compiled in a new R session, it won’t use any objects in your current R session. This is hard to replicate only through the envir argument of knitr::knit() in the current R session. In particular, you cannot use knitr::knit(envir = new.env()) because although new.env() is a new environment, it has a default parent environment parent.frame(), which is typically the globalenv(); you cannot use knitr::knit(envir = emptyenv()), either, because it is “too clean”, and you will have trouble with objects even in the R base package. The only reliable way to replicate what the “Compile PDF” button does is what I said in 1: system2("Rscript", c("-e", shQuote("library(knitr); knit('your.Rnw')")), in which case knit() uses the globalenv() of a new R session.

3. I’m not entirely sure about what RStudio does for the repos option. It probably automatically sets this option behind the scenes if it is not set. I think this is a relatively minor issue. You can set it in your .Rprofile, and I think RStudio should respect your CRAN mirror setting.

Users have always been asking why the Rnw document (or R Markdown documents) are not compiled in the current R session. To us, it basically boils down to which of the following consequences is more surprising or undesired:

1. If we knit a document in the current R session, there is no guarantee that your results can be reproduced in another R session (e.g., the next time you open RStudio, or your collaborators open RStudio on their computers).
2. If we knit a document in a new R session, users can be surprised that objects are not found (and when they type the object names in the R console, they can see them). This can be surprising, but it is also a good and early reminder that your document probably won’t work the next time.

To sum it up, I think:

• Knitting in a new R session is better for reproducibilty;

• Knitting in the current R session is sometimes more convenient (e.g., you try to knit with different temporary R objects in the current session). Sometimes you also have to knit in the current R session, especially when you are generating PDF reports programmatically, e.g., you use a (for) loop to generate a series of reports. There is no way that you can achieve this only through the “Compile PDF” button (the button is mostly only for a single Rnw document).

BTW, I think what I said above can also apply to the Knit or Knit HTML buttons, but the underlying function is rmarkdown::render() instead of knitr::knit().