Inconsistent scoping rules for exercise chunks

[garrettgman]

I've noticed that the code run in learnr exercise chunks has access to different environments depending on how the tutorial is launched. I expected the code in the exercise chunks to only have access to objects that are created in the setup chunks that are associated with the exercises (as well as the global setup chunk). I see different behavior in two cases:

1. Exercise chunks inherit the global environment of the local R session from which the tutorial is launched when the tutorial is launched from the command line with learnr::run_tutorial(). By this I mean that code run in the exercise chunks can use objects stored in the local global environment.

2. Exercise chunks inherit the knit environment of the document that they appear in when tutorial is launched with the GUI Run Document button. By this I mean that code run in an exercise chunk can use objects created in any of the document's normal knitr chunks. This may have something to do with pre-rendering because I do not notice the behavior the first time that I run the document, but on every subsequent run. So far, I've only seen this in local mode (launched from GUI), not on tutorials published on shinyapps.io.

I've hosted a learnr tutorial that describes and demo's these bugs in an attempt to provide a reproducible example: https://tutorials.shinyapps.io/scoping-rules/

[jcheng5]

Maybe related? #170

[schloerke]

So for exercises in the a learnr document...

• Setup
• A
• B
• C depends on A

It should make an environment tree like:

* Global Environment
* Blank Environment
   `-- Setup
      |-- A
      |   `-- C
      `-- B

Currently, it is executing exercise C user interactive code chunks with:

* Global Environment
   `-- Setup
      |-- A
      |   `-- C
      `-- B

... which should be pulling from a blank environment and not the global environment. (Addressing bullet # 2)

---

Independently, there is a separate issue in that when rendering the document, it should ALWAYS be rendered in a clean environment (like the RStudio IDE does) regardless of where it is rendered. (Addressing bullet # 1)

---

Correct?

[schloerke]

To address bullet # 1 : rstudio/rmarkdown#1204 . rmarkdown explicitly states that it will render in the current environment and will not support spawning a new session to render within a clean environment (like how RStudio implements 'knit file' button)

Gabor addresses the situation by having callr invoke rmarkdown render in a new session: rstudio/rmarkdown#1204 (comment)
This code can be adopted within learnr with the added dependency of callr

[schloerke]

@garrettgman To address bullet # 2, this is the current expected behavior: https://rstudio.github.io/learnr/publishing.html#fully-custom-evaluator

Currently, Mac and windows execute code in the local shiny envir, while linux forks the process before evaluating. This would explain the odd behavior on a local Mac and expected behavior on shinyapps.io.

---

@jjallaire Any reason why mac is not using a forked evaluator?

parallel packages provide a nice, efficient parallel programming platform for multiprocessor/multicore computers running operating systems such as Linux and Mac OS X.

doParallel - Getting Started - Chapter 9: Conclusion

[schloerke]

Joe informed me of some possible issues with httr and forking on Mac.

If we add callr as a new dependency, I should be able to solve both of these issues.

Does this seem reasonable?

[jjallaire]

The forked evaluator is really for situations where you are serving multiple clients (it's of limited use on the desktop as the single "user" of the tutorial doesn't really need concurrency). So, I wouldn't make any big changes with the motivation being to get forked execution working on the Mac (as it's unlikely to benefit any real uses cases)

[schloerke]

closed in #174

Please use
learnr::safe(rmarkdown::render(TUTORIAL)) and learnr::safe(learnr::run_tutorial(TUTORIAL, PKG))