Rework remote support to account for more scenarios

[rchiodo]

Remote support is confusing:

• Choosing/changing remote local servers is buggy and confusing. #10363
• Suggestion: Query clipboard permissions when opening an existing server instead of always prompting #10191

Using this issue to describe the use cases.

Use Cases

1. (web) User opens a notebook and wants to run a cell so they can see the output of a cell
2. (web) User is in a notebook and wants to run a cell in the browser so they don't have to pay for/setup a remote compute
3. (web) User is in a notebook and wants to run a cell on their local machine so they don't have to pay for/setup a remote compute
4. (web) User is in a notebook and wants to run a cell on a different remote server because this one is more expensive
5. (desktop) User opens a notebook and wants to run a cell without entering anything so they can see the output
6. (desktop) User opens a notebook and wants to run it on their own compute so they can use the GPU/CPU on that machine
7. (desktop) User wants to specify their own compute for all notebooks so they don't have to keep picking a server
8. (desktop) User wants to run some cells on local and some cells on remote (need to check telemetry for this)
9. (codespaces) User wants to run a cell and not have to specify anything except clicking the run button.

[rchiodo]

Use case 1 - Web run a cell.

Solution ideas:

• User opens notebook, run button is immediately available
• Command for 'Connect to your own jupyter server' appears.
• It loads UI for picking a URI. User has one step to enter the URI or pick from MRU list
• Once URI is picked, the 'default' kernel from the remote is selected and the cell runs.
• Jupyter:Local/Remote is removed from the UI as it's not necessary.

Solution idea 2:

• User opens notebook, run button is available
• Run just executes the command because it's the preferred kernel
• User picks URI? Seems confusing. Why am I being asked to pick a URI?

[rchiodo]

What does the user expect to be in the kernel drop down list?

What would their expectations be in these scenarios?

• Web first time - 'Connect to Remote Jupyter Server'
• Web second time - 'List of remotes and 'Connect to Another Remote'.
• Desktop first time - 'Connect to local? and Connect to Remote?' or 'Connect to local Jupyter Kernel, Connect to Remote Jupyter Server'
• Desktop second time - List of locals or remote based on what they picked. Option to pick the other.
• Codespaces first time - Connect to codespace? Skip connect to remote?
• Codespaces second time - List of 'locals'. Skip connect to remote?

[rchiodo]

Use case 2 - Web run a cell in the browser

Solution 1

• Depend upon pyodide in the web extension
• User gets option to use pyodide kernel automatically?

Solution 2

• Add command for 'Run in browser (with limited support)'
• This installs pyodide extension
• Runs cell with pyodide kernel
• Is it weird for jupyter extension to know about pyodide? Is there another way to surface this?

[rchiodo]

Use case 3 - Web run a cell on local machine

Solution 1

• Command to run on local machine
• It goes through the steps of reopening it in VS code locally? Or maybe installing the VS code server and using that as the entry point?

Could do this later, but command would be a way to kick it off.

[rchiodo]

Use case 4 - Web run a cell on a different remote server

Solution 1

• User opens notebook
• User has remote kernels in the dropdown by 'Connect to Remote' is still there
• User picks 'Connect to Remote'
• New remote kernel list and default are picked.

Solution 2

• User opens notebook
• User has remote kernels in the dropdown but each is prefixed/tagged with an alias.
• User picks Connect to Remote
• New kernels come back with new alias
• Default is picked again from new alias
• Old URIs are still there
  • How is the OLD uri removed?

[rchiodo]

Another problem: How does user on reopen know where kernels come from?

Solution 1:

• URI picker allows entry of 'alias'
• Alias is prefixed on every kernel
• This would also allow connecting to more than one server or local at the same time

Solution 2:

• Kernel picker has 'sections' per URI
• Alias could be used here too.

Do we need 'conda' 'venv', etc? Is there another way to surface this?

[rchiodo]

Use case 5 - Desktop open a notebook for first time

Solution 1

• User opens notebook
• Kernel list is populated as we find interpreters
• Preferred kernel is picked that
  • Matches python in path
  • Has ipykernel in it
  • Matches other notebooks in same workspace

Solution 2

• User opens notebook
• Only on first run of any notebook there is two commands 'Connect to local Jupyter kernel' and 'Connect to remote Jupyter Kernel'. Is this confusing though for remote ssh? Remote is an overload term.
  • Change to 'Run from local machine' and 'Run from Jupyter server'
• Run from local machine loads kernels and picks the 'preferred' always

[rchiodo]

Use Case 6 - Desktop use remote compute

Solution 1

• User opens notebook
• User picks 'Run from a Jupyter server' (and ignores the local kernels listed)
• Remote kernels are enum'd
• Default kernel is picked
• Cell runs

Solution 2

• User opens notebook
• User picks kernel
• Kernel picker shows
  • A kernel for every 'kernel spec' (remote or local)
  • The last 'custom' kernel picked.
  • 'Run with another local python environment'
  • 'Run with another Jupyter server'
• User picks 'run with another jupyter server'
• Default kernel is picked
• Cell is run
• Kernel dropdown now shows:
  • All remote kernel specs
  • Remote kernel already in use for notebook (selected)
  • 'Run with local python environment'
  • 'Run with another jupyter server'

[rchiodo]

Use case 7 - Desktop not have to pick remote

Solution

• User picks 'Select jupyter server for connection'
• Picks URI (not two step)
• All notebooks after this point show what happens as if they already picked the 'Run with custom jupyter server'

[rchiodo]

Use case 8 - Desktop some local, some remote

Solution

• User opens notebook
• User opens kernel picker
• Kernel picker shows:
  • List of kernelspecs based on if 'remote' or 'local' at the moment
  • 'Run with local kernel' (if currently remote)
  • 'Run with custom Jupyter server'
• User picks 'Run with local kernel'
• Quick pick is shown with
  • All local kernel specs
  • One for the 'default' python environment. Has to be clear which python this is.
  • One for 'custom python enviroment'
• User picks 'custom'
• Quick pick is shown with
  • Interpreter list
• User picks an interpreter
• Kernel is picked and cell is run
• Select kernel will now show:
  • Custom python kernelspec
  • All local 'jupyter' kernelspecs
  • 'Run with custom local python'
  • 'Run with custom Jupyter server'

[rchiodo]

Use case 9 - Codespaces

Solution

• User opens notebook
• Jupyter loads all python interpreters
• Detect codespaces
• Pick the newest interpreter
• Default just works

[rchiodo]

Use case 8 is probably the most fleshed out. Should create walkthrough for that.

[rchiodo]

Feedback from display

• Group to different sorting
• Back buttons on multi-step
• Use same command we have right now for selecting a server URI
• Setting for experiment
• Setting for 'preferred' or not. Some people like this. Some people don't (like auto start on kernel)

[rchiodo]

Feedback from UX sync

• One button for pick another local kernel (language separation is weird)
• Don't use Run button

[rchiodo]

Switch to a 'mru' list instead of 'local' vs 'remote'

[rchiodo]

Miguel's feedback:

[rchiodo]

Notes:

• We need to have something in the MRU list. If the user has never opened a notebook in this workspace, it should reflect either the default remote kernel or the 'default' local kernel. A 'good' kernel.
• There would be no 'remote' or 'local' mode. It would just be an MRU list

[rchiodo]

• Connect to Local kernels = Connect to Other Local Kernels ? Where are the rest of the local kernels?. Other kernels is what Jupyter lab calls it.
• Busy status on remote list
• Sort order won't follow MRU list. How to resolve this? Priority? Use hidden UTF 8 chars on the kind?

[rchiodo]

Another idea:

• Locals with command at bottom - connect to remote
• Remote with command at bottom - connect to local