Support for ipycytoscape in Google Colab

[rchurt]

Hello,

I've been hoping to use ipycytoscape in Google Colab for a while, and it looks like it's finally possible now that Colab has started supporting custom widgets. Specifically, as @blois explained, "Colab recently started exposing Jupyter Comms channels so custom visualizations can use them for communicating with the kernel (see https://colab.sandbox.google.com/notebooks/snippets/advanced_outputs.ipynb#scrollTo=YOd4khppTskD)." However, because the required jupyter-cytoscape extension is written for JupyterLab, some changes need to be made for it to work with Colab. I'm not sure exactly what those are, but I'm hoping that between the ipycytoscape team and @blois we can figure them out, possibly resulting in a new extension colab-cytoscape.

More info on portable widgets for Colab here

Related to colabtools/issues/1524. Possibly tangentially related to #80.

[ianhi]

Hi @rchurt, I agree that this would be great! Unfortunately, my reading of the linked issues is that this is more of a google colab problem than an ipycytoscape problem. I think the suggestion in those threads is that with the new colab support for comms you can work around colab not supporting widgets by injecting javascript via IPython.display.javascript. However, I think you'd need to inject quite a lot of javascript and I don't think there's a clean way to do that.

I definitely could be wrong/misreading things here though. I'd be happy to be shown how this is in fact possible.

[blois]

It depends on how much Javascript is needed- some libraries will directly inject the javascript using IPython.display.javascript as you mention- it may not be elegant but it does ensure the notebook is self-contained and can be viewed by all users at a later time. Other libraries such as Bokeh and Plotly use CDNs to host versioned copies of the libraries. They typically offer some configurability to allow loading resources locally for users sensitive about remote resources and CDNs for users who may want their notebooks to be more easily viewed later.

[timkpaine]

jupyterlab extensions that dont rely on jupyterlab-specific windowing or apis should work out of the box, which includes most ipywidgets based libraries.

[timkpaine]

e.g. ipycytoscape exports jupyter notebook compatible js assets here: https://github.com/QuantStack/ipycytoscape/blob/master/webpack.config.js#L19

[timkpaine]

in general though, google colab is a proprietary product and the onus is really on google to support what the open source community deems as standards

[blois]

I am definitely open to suggestions on improving the situation- some background can be found at https://github.com/nteract/nes/tree/master/portable-widgets.

I'm not sure what the standards are here- I don't think there's any feasible way to make JupyterLab extensions work outside of JupyterLab. If there is no desire to support anything other than JupyterLab then that is fine. You can see my goals in the background section of the above link and I do believe that those goals would be beneficial to everyone.

Also take a look at https://github.com/Quansight-Labs/jupyter-output-spec which I've been helping out on as well and is an approach for the issue. I did a prototype implementation of this for Jupyter Lab at https://github.com/blois/js-module-renderer.

The basic model that we've been using is to display visualizations with HTML/JS then if comms are available to enable bi-directional kernel communication. The comms APIs in Colab are intended to be similar to those in Jupyter Notebook to allow more portability, but unfortunately they cannot be identical since there is a lot of code which looks for window.Jupyter and when that is defined will make broad assumptions about executing within Jupyter Notebook.

[rchurt]

Thanks for all the helpful discussion! I think this link from @blois describes the problem well--ipycytoscape folks, what's your current approach to offering support for multiple platforms (nteract, voila, nbconvert, etc.)?

[marimeireles]

I'm not sure what the standards are here- I don't think there's any feasible way to make JupyterLab extensions work outside of JupyterLab.

@blois
You mean that extensions that run in the notebook can be used in colab but the ones that only run on jupyterlab can't?

My take on this is that I'd like to have ipycytoscape supported to colab because I think it'd be beneficial for the community but I have to agree with @timkpaine, colab is a proprietary product and the onus to support it belongs to google. Also, if I was to make these changes I'd have to learn a few things about the low level functioning of Jupyter, so it wouldn't be trivial for me.

This seems very interesting: https://github.com/blois/js-module-renderer
What's the state of it? Does it convert some specific kinds of extensions automatically? Or does it always require human input? Also, this is converting to other rendering engines or just colab?

what's your current approach to offering support for multiple platforms (nteract, voila, nbconvert, etc.)?

@rchurt
Never tried with nteract nor Jupyter sphinx, but ipycytoscape works fine with voila and nbconvert because I tested it.
If either you or @blois are interested in making this port you're welcome to ask me questions here or in the gitter chat.

[saulshanabrook]

Hey @marimeireles, I am the original author of https://github.com/Quansight-Labs/jupyter-output-spec which @blois's work builds on.

If you are interested in helping move this forward, I am happy to try to explain here the state of things or get on a call. I think it would do a lot to help the whole Jupyter community by improving interop between the frontends and making them less siloed. However, I don't have the bandwidth right now to work on it alone.

[timkpaine]

Nteract, voila, Sphinx, nbconvert, jupyter, and jupyterlab all work out of the box with the widget cookiecutter assuming you don't need to do anything super custom. I would say this issue should probably be closed as it doesn't make too much sense to build custom functionality here instead of in the cookiecutter that we all rely on underneath.

[timkpaine]

https://github.com/jupyter-widgets/widget-ts-cookiecutter
https://github.com/jupyter-widgets/widget-cookiecutter

[ianhi]

I would say this issue should probably be closed as it doesn't make too much sense to build custom functionality here instead of in the cookiecutter that we all rely on underneath.

I very much agree with this. Unless @marimeireles disagrees I think we should close this and move this discussion over to the jupyter-widgets organization. As for Ipycytoscape support, I feel comfortable saying that it will continue to be updated to reflect any changes to the cookiecutter, so any solution will ultimately end up here as well.

If you are interested in helping move this forward, I am happy to try to explain here the state of things or get on a call. I think it would do a lot to help the whole Jupyter community by improving interop between the frontends and making them less siloed. However, I don't have the bandwidth right now to work on it alone.

I'm all for more widgets in more places! @saulshanabrook I think a good place to discuss that may be the jupyter-widgets meetings: https://github.com/jupyter-widgets/team-compass#bi-weekly-team-meetings-every-other-week

[marimeireles]

I feel comfortable saying that it will continue to be updated to reflect any changes to the cookiecutter, so any solution will ultimately end up here as well.

Yes, seems like a good one :)

[marimeireles]

edit: actually, thinking this further, I'm not so sure if it'd be a good idea to incorporate it to the main cookiecutter.
It depends - I guess - on the amount of changes and the overhead for devs to implement it, maybe a side cookiecutter is the answer for this? Idk, but I'm interested in the developing of this. Would be cool to hear more about it in the widgets meeting.
Cheers!