-
Notifications
You must be signed in to change notification settings - Fork 242
Improve run_tutorial()
#601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
rossellhayes
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just a small typo!
Co-authored-by: Barret Schloerke <[email protected]> Co-authored-by: Alex Rossell Hayes <[email protected]>
|
Update: I also added support, turned on by default, for running a tutorial as a background RStudio job. The tutorial opens wherever shiny apps open by default, using the In theory, we could also open the tutorial in the Tutorials pane, but since there isn't a public API for stopping Rstudio jobs, we'd end up having to build too much infrastructure to achieve parity with the built in tutorial running methods. That's another reason why I decided not to go further; the RStudio tutorial pane depends on |
We don't directly need this version in learnr code but we might as well encourage learnr users to have the appropriate version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor changes.
- Remove multi-Rmd-file logic warning in
available_tutorials_for_package() - Add Breaking Change news item about
shiny_argsnow being after...
Otherwise LGTM!
Co-authored-by: Barret Schloerke <[email protected]>
and then re-use that logic in `available_tutorials()` and `run_validate_tutorial_path_is_dir()`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad I let this sit for a little bit. Coming back to look at it again, I think the restriction that name be a directory when referring to a local file feels too arbitrary.
I stuck with the directory approach because we move the tutorial directory to a temporary location if we don't have write access where the tutorial is stored. That logic makes sense when the tutorial is hosted in an R package, which may be stored in a location that's inaccessible to the end user. But it doesn't make sense for a local file.
I'm going to update the PR to accept a specific file in name. If a file path is provided but the directory isn't writeable, we'll throw an error rather than copy the directory.
This comment has been minimized.
This comment has been minimized.
108395d to
8d695fd
Compare
8d695fd to
0a52061
Compare
rossellhayes
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, I just caught a few typos and one potential small improvement
Co-authored-by: Alex Rossell Hayes <[email protected]>
Brings a few new features to
run_tutorial():Allow
nameto take a path to local tutorial directory. Thenamemust be an existing directory andpackagemust beNULL. Sincerun_tutorial()manages the tutorial directory and uses thedirargument ofrmarkdown::run(), we pre-emptively thorw an error if there is more than one.Rmdin the directory and none are namedindex.Rmd.Add arg
cleantorun_tutorial(), cleanly re-render the tutorial whenTRUE. We follow the same logic used in validating the tutorial directory to identify the tutorial.Rmdfile, sincermarkdown::shiny_prerendered_clean()requires a specific file rather than a directory.Launch tutorial in viewer pane by default, if possible. It's not currently possible to open tutorials in the tutorial pane interactively, but by giving
launch.browsera function, we have a place to modify this in the future.Fixes #600
Fixes #333