Support for JupyterLab
Is your feature request related to a problem? Please describe
Currently Gitpod supports a couple of editors and IDEs by default:

However these editors are mostly meant for software developers writing code and could be intimidating for other categories of developers.
Describe the behaviour you'd like
Some Data Scientists might also be interested in using Gitpod for their work.
But they might be more familiar with user interfaces like JupyterLab or Jupyter Notebook.
So it would be great if Gitpod could provide support launching JupyterLab as well.
Describe alternatives you've considered
With GitHub Codespaces it's possible to set JupyterLab as the default interface:

Currently on Gitpod it's also possible to install JupyterLab with pip install jupyterlab and launch it via a command with something like:
jupyter lab --no-browser --LabApp.token='' --LabApp.allow_origin=* --LabApp.tornado_settings='{"headers": {"Content-Security-Policy": "frame-ancestors *"}}'
But this still requires launching VS code and then opening the service (running on port 8888 by default) in another browser tab to access the JupyterLab interface.
Thanks @jtpio ! This is definitely something that have / are considering. We're also looking into ways to make our IDE interfaces more configurable, so they could be community owned, maintained and suggested more freely.
+1. I'm an instructor that usually works with data scientists and I am looking into ways to use JupyterLab as the default, and later on switch back to VSCode.
Inspired by that JupyterLab itself does (see their .gitpod.yml), this is what I'm testing on my projects:
tasks:
...
- name: Launch JupyterLab
init: |
gp sync-await dependencies
python -m pip install -r dev-requirements.txt
# Inspiration: https://github.com/jupyterlab/jupyterlab/blob/a920f33/.gitpod.yml
# and https://github.com/gitpod-io/gitpod/issues/16306
command: |
jupyter lab --port 8888 \
--ServerApp.token='' \
--ServerApp.allow_remote_access=true \
--no-browser
ports:
- port: 8888
But still usually requires me to explain participants that
- they have to ignore VSCode for a moment,
- they must locate the button "open browser", or if they are not quick enough, the ports view
- they must allow pop-ups from their browser
Not the end of the world, but a bit cumbersome.
There is no heartbeat, so workspace will eventually time out because of inactivity.
There is no heartbeat, so workspace will eventually time out because of inactivity.
Right, that is one major drawback of the current workaround.
It in theory it should be possible to create JLab plugin which grabs workspace token from supervisor, tracks DOM events for activities (mouse, keyboard) and reports them to Gitpod API, similarly how VS Code Web integration does it.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
activity