Run R-Client in Jupyter Notebooks
przell opened this issue · comments
| Title | Run R-Client in Jupyter Notebooks |
|---|---|
| Date | 2021-11-18 |
| Issue | #95 |
| Category | Usability, integration openEO platform |
| Description | OpenEO platform hosts jupyter notebooks as the default entry point for programming on the platform. To facilitate the uptake of the R-Client in openEO platform it should be verified that the R-Client runs in jupyter notebooks when using R as the kernel and that all visualizations work as in R-Studio. |
| Dependencies | Jupyter, Device Code Authentication |
| Links | Integration of Vue components, mapview in jupyter |
| Priority | Medium |
| Impact | Medium |
Although in principle we now have supprot for visualizations in Jupyter, there are still some uncertainties about the auth procedure. Right now it works, but once we migrate back to the httr2 code, it may break again due to this issue: r-lib/httr2#111
@flahn proposed to check the following in Jupyter:
- Remove the change to allow non-interactive usage (see #104)
- Check whether we can use login with
rlang::with_interactiveorrlang::local_interactive
So rlang::with_interactive(login(),value=TRUE) or rlang::local_interactive() and then login()
rlang::with_interactive(login()) does work always (but is cumbersome to document for us and people may forget it). But can we simply wrap the httr2 function call (oauth_flow_device?) for device code with this in login() so that users don't need to bother?
rlang::local_interactive()
login()
Seems to be unreliable. Sometimes it works, sometimes it does not work. Calling login twice usually works. So it looks like local_interactive needs more time to take effect. Strange. Do you have a clue why that is, @flahn ? Is it because of what is documented for the "frame" parameter? "When the function returns, the options are reset to their original values."
Created a solution in PR #119