Skip to content
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

Offer RStudio as default frontend for R users #29

Open
pierrepo opened this issue Jun 23, 2020 · 7 comments · May be fixed by plasmabio/plasma#176
Open

Offer RStudio as default frontend for R users #29

pierrepo opened this issue Jun 23, 2020 · 7 comments · May be fixed by plasmabio/plasma#176
Labels
enhancement New feature or request

Comments

@pierrepo
Copy link
Contributor

RStudio is very appreciated among R users and is often the ad-hoc IDE.

By default, RStudio is injected into the environment when repo2docker detects an R environment.

It would be very nice to allow in the environment creation box to start directly with RStudio (instead of Jupyter Lab). It could be a box to tick, for instance:

[ ] start with RStudio instead of Jupyter Lab (R environments only)

There are however some caveats:

  • I believe tljh-repo2docker is not aware of the content of the environment (Python, R...) so someone could tick the box even if the environment is not R-based. I'm not sure what could happen next. Probably a 404 : Not Found
  • Within RStudio, user lost integration with Jupyter Hub (Hub Control Panel in the File menu) and there is not easy/visual way to go back to the control panel (although the url is very easy to manipulate).
@pierrepo pierrepo added the enhancement New feature or request label Jun 23, 2020
@jtpio
Copy link
Member

jtpio commented Jun 24, 2020

This would mean changing the default URL to /rstudio?

I'm not sure what could happen next. Probably a 404 : Not Found

Yes that would most likely be a 404

@pierrepo
Copy link
Contributor Author

This would mean changing the default URL to /rstudio?

Yes, replacing the trailing /lab part in the URL by /rstudio. At least, this is how I do manually.

@jtpio
Copy link
Member

jtpio commented Jun 25, 2020

It sounds like it should be possible to do that directly in the environment being built, maybe in the postBuild or start files.

There has been a few discussions about having non-Jupyter IDEs / UI by default in repo2docker / Binder:

We would also need to rework the default_url there: https://github.com/plasmabio/plasma/blob/a9f4530948109543b6efc5014194e460b36888de/tljh-plasma/tljh_plasma/__init__.py#L111

@pierrepo
Copy link
Contributor Author

It sounds like it should be possible to do that directly in the environment being built

That would the best case:

  • No need to modify the UI.
  • Responsability of the env creator to chose the suitable frontend

But as far as I understood, it is not obvious (nor possible?)

We would also need to rework the default_url

Yes. And also if the frontend is passed through the UI.

@jtpio
Copy link
Member

jtpio commented Jun 25, 2020

But as far as I understood, it is not obvious (nor possible?)

Indeed it might not be straightforward (at least for now).

Otherwise the downstream TLJH plugin (such as Plasma) could implement some logic to set the default_url on the fly when the server is started, for example based on the name of the environment.

@pierrepo
Copy link
Contributor Author

This kind of Binder Menu is also very interesting and could allow to jump from one frontend to another.

@jtpio
Copy link
Member

jtpio commented Jul 6, 2020

This kind of Binder Menu is also very interesting and could allow to jump from one frontend to another.

That would definitively be useful 👍

An alternative for now is to give user a URL to connect to JupyterHub that includes a /user-redirect/rstudio route:

https://dev.plasmabio.org/user-redirect/rstudio

The flow would look like the following:

user-redirect-rstudio

@jtpio jtpio linked a pull request Jul 7, 2020 that will close this issue
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants