Rename the Pyolite kernel about jupyterlite

[bollwyvl]

How about ipylite? Short, not taken, decent mashup of the two?

[jtpio]

Another option would be to use the "Python (Pyodide)" display name, similar to "Python (ipykernel)" and "Python (XPython)" in regular Jupyter.

And use the jupyterlite-pyodide-kernel package name to distribute it once it's moved to a separate repo: #386

[bollwyvl]

@jpio on #129

So now might be a good time to start having a minimal IPython (mostly IPython.display) that would run in jupyterlite.

Indeed! But answering the API mail exactly on #18 will need this anyway for e.g. bokeh or freaky-deaky wrapper kernels that subclass KernelBase.

So, offspring-of-pyolite probably needs to not only offer an importable IPython and ipykernel, but also distributions named ipython and ipykernel that have version-equivalence with the "real ones" on PyPI.

Further, as the pyodide one is, for the time being, by far the heaviest kernel, it ideally needs to be distributed as its own package(s), that is/are on PyPI, a la #104. So the notional real {sys.prefix}/share/jupyter of the building environment after installing these package(s) might be something like:

share/jupyter/lite/pyodide/
  ipython-7.24.0-py3-none-any.whl
  ipykernel-5.5.5-py3-none-any.whl

...and build up a compatible index similar to how we're doing contents for now.

Starting to get pretty fractal at this point, as these would also be .whls that someone could micropip.install().

cc @Carreau

[Carreau]

Happy to do changes needed in IPython and reduce the size. I doubt I'll have time myself.

[bollwyvl]

@Carreau No worries! I don't think we'll need any changes upstream, just alerting you that there might be another whl-in-a-whl of IPython on the horizon that only works in the browser. all the zmq stuff, etc. is basically a non-starter, and we're going to have to fake it. But luckily no windows problems!

[jtpio]

As a start we probably don't need the whole ipython, but mostly its display the module? And being able to configure or override the publish_display_data.

That would indeed also mean having the distributions as well, but those could be recreated by assembling pieces from the upstream ipython.

For ipykernel, more modularity would also benefit other projects like xeus-python, which patches the comms.

[psychemedia]

Here's an interesting package for viewing 3D molecules in the browser — py3DMol [example] — that explicitly tests for IPython but I think only really depends on the IPyhton.display tools?

https://github.com/3dmol/3Dmol.js/blob/master/py3Dmol/py3Dmol/__init__.py

It also makes use of publish_display_data().

May be useful as an in-the-wild test case.

(FWIW, I know of quite a lot of packages out there that render widgets into notebooks using HTML/js but that don't make use of ipywidgets callbacks.)

[UPDATE: now installs and can be imported but currently fails with AttributeError: module 'IPython' has no attribute 'display' from where it makes a call to publish_display_data()]

[jtpio]

How about ipylite? Short, not taken, decent mashup of the two?

Sounds good 👍

Just booked it on PyPI: https://pypi.org/project/ipylite

[echarles]

Another option would be to use the "Python (Pyodide)" display name, similar to "Python (ipykernel)" and "Python (XPython)" in regular Jupyter.

Simple and descriptive

+1

And use the jupyterlite-pyodide-kernel package name to distribute it once it's moved to a separate repo: #386

Simple and descriptive

+1

@jupyterlite/pyodide-kernel would also work.

[jtpio]

Another option would be to use the "Python (Pyodide)" display name, similar to "Python (ipykernel)" and "Python (XPython)" in regular Jupyter.

This was fixed in #685 and is already available in the latest releases.

@jupyterlite/pyodide-kernel would also work.

Yes that would likely be the name of the underlying JS package 👍