-
Notifications
You must be signed in to change notification settings - Fork 947
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
Create basic comm API shim for jupyter-js-services #264
Conversation
Sweet. Thanks for jumping on this. Definitely looks like what I was envisioning. So on our end we'd have to instantiate and pass the shim to the WidgetManager, plus alias the /cc @lbustelo, @dalogsdon @jhpedemonte who are all closer to widgets / dahsboards JS than I have been |
Actually, that's not what I was intending. The WidgetManager you reference is intended for notebook use only, it'd surely break outside of the notebook. Instead my suggestion is took take something like I'll add another example to this PR clarifying what I mean and demonstrating jupyter-js-services powered widgets outside of the notebook. |
this is required to make the relative paths work correctly.
This is ready to go now! See |
Looks like you had to poke into the private API, feel free to push back on what the API needs to look like. |
Pretty awesome indeed. Gino B.
|
@lbustelo and I poked around earlier while you were working up the new demo. Totally get it now. Implement a subclass of the base widget manager. Instantiate the shim. Override the necessary methods. Away you go. Looks great. |
Thanks, I know that ipywidgets actually uses some of the private methods of the old API too. The private methods used in the shim may not be essential. I'll have to dig deeper into the code to remember what the reasoning was for creating comms that are unregistered and unknown to the manager (the kernel, in jupyter-js-services's case). It may be that no changes are needed to the new API when I drop the old comm API completely. |
@SylvainCorlay this PR also fixes some hiccups introduced in the examples by #261 |
Actually, I just looked, we aren't using any private APIs in master right now, so we must have fixed that at some point. |
Why moving the |
@blink1073 the only lines that are causing me to use private APIs ATM are these: https://github.com/ipython/ipywidgets/blob/master/ipywidgets/static/widgets/js/manager.js#L260-L262 They create a comm and don't send a comm open message. Looks like the new API supports this, as |
I had trouble with it complaining about missing dev-dependencies of ipywidgets otherwise. Basically, in order for the funky relative dependency that we have to work, the sub projects have to be inside the parent project's directory. My theory is that npm walks outwards for node_modules folders looking for binary dependencies. I found this out because I don't have |
It is weird because I did not have such issues with bqplot while requiring ipywidgets which was not in a parent project directory. |
@jdfreder, |
I just double checked and it looks like I can move them back. Now I think what I was seeing earlier was caused by a separate problem, which was that I hadn't ran |
Awesome, I shouldn't need any private members when I make the full transition to jupyter-js-services. Also, I just checked, and the old API methods I'm emulating, that do need private members of jupyter-js-services, aren't even being used by the example, so I went ahead and removed them. There shouldn't be any more private member usage now. |
Great, glad to hear it. |
if (callbacks) { | ||
future.onReply = function(msg) { | ||
if (callbacks.shell && callbacks.shell.reply) callbacks.shell.reply(msg); | ||
// TODO: Handle payloads. See https://github.com/jupyter/notebook/blob/master/notebook/static/services/kernels/kernel.js#L923-L947 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should update KernelFuture to handle this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, I don't think so. As you know, the channels are shell
, iopub
, and stdin
. The payload handler acts on shell messages. In the spirit of minimal message processing at the kernel level and the 'hand the full message to the handler and allow it to decide what to do with it' thinking, it makes sense to not handle this in the kernel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, that was my reasoning as well.
Thanks for moving examples back. I have build scripts that fetch this directory and I wanted to be sure it is not moving. |
Adding font-awesome's css and top-level requirement for npm
LGTM. |
Jupyter js widgets + web example requires node-lessify
Create basic comm API shim for jupyter-js-services
🎉 |
Nicely done! |
💥 yay! |
Here's a simple shim that allows use of jupyter-js-services via the old comm API.
@parente @blink1073