Fixes for learnr to external evaluator

[nischalshrestha]

Description

Problems

When using the "new" (commit >= bd29e0c) learnr against an "old" (commit: cf5fe34) learnr on the external evaluator, there are evaluator and feedback return issues:

• the evaluator always returned four empty lines for every exercise.
• the engine for R exercise needs to be capital "R" not "r"
• the exercise$options$code for some reason gets reused as exercise code instead of exercise$code, which causes the external server to always run the original exercise code (from knitr chunk) instead of the user code.
• regular setup code will not work because the exercise$setup is always NULL since we now store all setup chunks in a exercise$chunks list.
• exercise.checker for new learnr caches function which causes issues on deserializing on external evaluator.

This is because the exercise structure for new learnr changed by: 1) forwarding all knitr options to evaluation, which causes a problem when sending some exercise$options fields like eval (produces for empty lines), and 2) exercise.checker was treated as a function when caching exercise.

Fixes

• In knitr-hooks.R, removing the exercise$eval field fixes the empty lines issue, while removing exercise$options$code makes sure the old learnr executes user code, NOT original knitr chunk code.
• The exercise$options$engine will be removed on external evaluator (as both old learnr and new learnr do not directly use it).
• To fix regular setup* code for exercises, I added back an exercise$setup in knitr-hooks.R (another field for cache), which contains either NULL if there is not setup code, or a character containing all of the setup code required (newline separated).
• exercise.checker for new learnr is back to being a character, so now all learnr versions will stick to this format.

*Note: this means that regular exercise setup will work, but chained will not, especially if there is non-R setup chunks.

You can test the solution by running evaluator-tests.Rmd learnr document and going through all tests in the tutorial.

[trestletech]

Looking good! I think my intuition is that we'd want to keep the all_setup_code change to ensure backwards compatibility. But the other changes strike me as things that could live inside the external evaluator instead of learnr having to eternally jump through hoops to present the exercise in a compatible format.

[trestletech]

We discussed and the root of the problem here is that learnr recently attached arbitrary properties it gets from knitr to each exercise. It turns out that some of the properties cause problems when interacting with old learnrs in a remote evaluator.

Given that these changes were recently introduced and we're basically just scrubbing a couple of known-problematic fields off of the exercise, this doesn't feel so out of place to me.

I vote we move forward with this approach but moving forward do some work to think about how we can better capture what structure an exercise is supposed to have so that others (e.g. remote evaluators) can confidently interact with them.

[schloerke]

Supporting v0 learnr exercises will get hard quickly moving forward. The changes made to support all_setup_code are isolated, but I'd like to time box (via CRAN releases) the v0 support to allow for growth.