-
Notifications
You must be signed in to change notification settings - Fork 291
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
Comms support #18
Comments
If we can implement comms, ipywidgets might work for free? |
I think @ibdafna was looking into it at some point and it should be feasible in theory. It's possible that the main issue for now is the dependency on So having a lighter ipywidgets which could be a fork, or maybe by splitting parts of ipywidgets into several packages might work. |
Indeed the ipykernel dependency might be annoying. The ipykernel dependency is because it provides the Python Comm implementation. We had this issue in xeus-python as well, and we had to monkey patch ipykernel to inject our own Comm class (see this code). This might be needed in this pyodide case as well, although it is not a nice solution. I started a discussion here: jupyter-xeus/xeus-python#342 to hopefully find a solution to have a cleaner way for the "current" kernel to expose the comms implementation. Maybe using entry-points might be the key. |
One thing to consider: while we don't want to bite off re-implementing the entire widget stack, comms will be useful in many kernels. For example, we've considered replacing/augmenting bespoke websockets with comms for delivering LSP https://github.com/krassowski/jupyterlab-lsp/pull/278. So: having this at the base js kernel level, and offering something that spans the inevitable webworker divide, with an initial in-worker python implementation, would be an interesting example of getting more features into more kernels. It seems like basing it on the [ipykernel CommManager][https://github.com/ipython/ipykernel/blob/master/ipykernel/comm/manager.py#L17) isn't the worst idea. |
Re: ipywidgets, I just started trying to go through the dependencies required to install it and get stuck with a missing core package (
|
The |
https://github.com/davidbrochart/kernel_driver might be a good candidate. |
Do we really need a jupyter client? The messaging part (in TypeScript) of the kernel would forward messages to the Python kernel. Then we'll need the Actually this might also require more patching / mocking of other packages like |
I'm sure there will be reason enough to eventually support I do like being able to rely on having access to a shell, so (IPython.)get_ipython gets my 👍! I think we just need to look at real AP access patterns in the wild to figure out what we need to patch in the near term. And, of course, any time we can write things that work with more client kernels than the pyodide-based one, the less work it is to add the next language. I'll see if i can get something quacking... |
Right, I think we win if these two PRs (#141 and #145) can be harmonized, but prettied up, moved to some new packages...
In It's good we a couple robust kernels kernels to kick this against, and we should try to leverage this towards making it relatively easy to add Comm support to a novel kernel, either "in-loop," for future js-based ones (e.g. .ts) or |
Will this actually work? The Pyolite python code running in a web worker it might not be possible to pass the JS comm implementation. |
At it's simplest, I'm imagining the following pattern [around here](python code running in a web worker it might not be possible to pass the JS ). const blob = new Blob([
[
`importScripts("${commManagerUrl}"});`,
`// secretly this did: this.comm_manager = new CommManager()`,
`importScripts("${pyodideUrl}");`,
//... Then from inside python, the implementation would be like: import js
comm = js.jupyterlite.comm.Comm({"kernel": js.kernel }) Where that |
@martinRenou can we start using https://github.com/ipython/comm? |
I think we can, I will still need to keep the |
Closing in favor of jupyterlite/pyodide-kernel#37 For reference, this should work out of the box in the xeus-python kernel now: emscripten-forge/recipes#602 |
How easy do you think it would be to add comms support?
The text was updated successfully, but these errors were encountered: