Build with JupyterLite 0.5.0 + Pyodide kernel 0.5.1, plus miscellaneous JupyterLite REPL updates

[agriyakhetarpal]

Description

This PR updates the SymPy Live shell so that the deployment can be built with JupyterLite 0.5.0 (upper-pinned to 0.6.0, matching that of jupyterlite-pyodide-kernel). jupyterlite-pyodide-kernel has been bumped to 0.5.1. which is slightly more reliable and a bit faster; it bumps to Pyodide 0.27.1 (which retains SymPy 1.13.3, similar to Pyodide 0.27.0). An inline comment with links to the documentation has been added as a compatibility note if we want to update the versions further with upcoming Pyodide releases.

On the REPL side, JupyterLite brings a new ?execute=0 URL parameter that populates the prompt with the SymPy initialisation code snippet, without executing it. This should be helpful with saving bandwidth on the load, as the code won't run automatically until the user presses Enter. &toolbar=1 and &kernel=python have been added explicitly rather than implicitly to guard against any possible breaking changes upstream, and they control the visibility of the toolbar with the kernel options (Run/Restart/Clear) and perform the auto-selection of the kernel respectively.

The JupyterLite source maps have also been disabled, which makes the JupyterLite deployment come down by 70.9% from 56 MiB to 16.3 MiB. This has also been applied for SymPy's interactive docs in sympy/sympy#27419 and was inspired by scikit-learn/scikit-learn#26246.

[ivanistheone]

JupyterLite deployment come down by 70.9% from 56 MiB to 16.3 MiB.

Wow nice!

JupyterLite brings a new ?execute=0 URL parameter that populates the prompt with the SymPy initialisation code snippet

Could you say a few more words about this form technical and UX perspective?

1. Do you mean it saves bandwidth since sympy will only get fetched after pressing enter? (I think it will be the same overall, since we have to execute the code later)
2. From UX perspective, I think this change might be detrimental: the user waits once for the JupterLab interface to load, then waits a second time to run the first command.

Then again if the initial load is faster it might be better overall... I'll have to check out the PR later today and play with it on different internet connections to see what happens, but I'd like to hear your reasoning/intent for adding the execuse=0 URL param

[agriyakhetarpal]

JupyterLite brings a new ?execute=0 URL parameter that populates the prompt with the SymPy initialisation code snippet

Could you say a few more words about this form technical and UX perspective?

1. Do you mean it saves bandwidth since sympy will only get fetched after pressing enter? (I think it will be the same overall, since we have to execute the code later)
2. From UX perspective, I think this change might be detrimental: the user waits once for the JupterLab interface to load, then waits a second time to run the first command.

Then again if the initial load is faster it might be better overall... I'll have to check out the PR later today and play with it on different internet connections to see what happens, but I'd like to hear your reasoning/intent for adding the execuse=0 URL param

Thanks for your review!

Yes. &execute=0 saves bandwidth when loading the page, but the bandwidth cost would be the same overall – if a user presses the Enter key, that is. My intent here is for the user to be able to decide whether to run the SymPy code snippets or not, as they have no control over the current option. Another benefit is that they can just run from sympy import *, or customise the command before they run it to their liking (e.g., for SymPy to be able to recognise that Flint is present in the environment: #23 – when python-flint becomes available in Pyodide)

Your point about having to wait for JupyterLite to load and then to run the first command makes sense as well... but if it's any consolation, loading JupyterLite takes substantially less time on my machine in comparison to running the SymPy code 😄

A follow-up question I have is that if we are to accept &execute=0, would it make sense to disable the terminal interaction mode, which is currently enabled?

[ivanistheone]

A follow-up question I have is that if we are to accept &execute=0, would it make sense to disable the terminal interaction mode, which is currently enabled?

This was enabled as a considerations for users on mobile, who can't press SHIFT+ENTER.
I know it breaks the usual jupyter lab/notebook keymap convention, but we need to be considerate for the mobile users.

[agriyakhetarpal]

Ah, thanks for the context. I did think about that angle recently; would a small physical "Send" button (like this unicode symbol: ⮚) be a solution for mobile devices, similar to how one sees in messaging apps? Such a button would have to belong in JupyterLite upstream though, as it wouldn't be a good idea to maintain it here.

[agriyakhetarpal]

Also, in that case, I assume that using &execute=0 and terminal mode enabled would be a bug on desktop devices, as it's not possible to add a multi-line code snippet and/or go to the next line. Either that would need to be documented as incompatible, or a workaround would be needed upstream.

[ivanistheone]

I tried the shell with execute=0 and I found it confusing so I would recommend we skip that from the query var.

This option makes more sense in the docs where the user might want to edit or customize the code snippet before they run it, but not for the interactive shell.

For reference, the command line isympy shell helper executes the same init code.

[ivanistheone]

I tested again and it's working as expected locally.

It's great we are tracking the versions jupyterlite-core and jupyterlite-pyodide-kernel as in the demo repo because those are known good.

Looks good to merge.

[agriyakhetarpal]

Thanks for reviewing it! :)

[agriyakhetarpal]

I bumped to https://github.com/jupyterlite/pyodide-kernel/releases/tag/v0.5.1 in the previous commit, which brings https://github.com/pyodide/pyodide/releases/tag/0.27.1.

This should be ready to merge now. Thank you for granting me push access to this repository earlier in the day – though I think it makes sense that you should push the green button :D

[ivanistheone]

Looks good. Merging now.

[ivanistheone]

Okay we're live. The speed improvement is very impressive.

Here are some test URLs I use to check that the evaluate commands are working:
https://minireference.com/static/tmp/sympyjstest.html = bit.ly/sympyjstest

Normally when I try these on mobile, it takes 30+ seconds each (I have an old phone), but load and run takes just a few seconds.