Support for ipycytoscape

Bug report for Colab: http://colab.research.google.com/. Related to #60.

• Describe the expected behavior: I’d love to use ipycytoscape to work with network graphs in Colab. I’m able to install it without a problem, but when I try to display a network graph, nothing shows up. Reminiscent of trying to display a HoloViews plot without having run hv.extension('bokeh') in the cell.

• The web browser you are using (Chrome, Firefox, Safari, etc.): Chrome 84.0.4147.135

• Link (not screenshot!) to a minimal, public, self-contained notebook that reproduces this issue (click the Share button, then Get Shareable Link):

Here’s a self-contained example from their website (you can find it and others here). After running the last line I would expect to see a network graph, but nothing shows up.

!pip install ipycytoscape
from ipycytoscape import *
import pandas as pd

df = pd.read_csv("https://raw.githubusercontent.com/nextstrain/ncov/fe5a7ed1f92af63d6d1d43d0307e4b2620108aaa/data/metadata.tsv", sep = '\t')
df.columns

cytoscapeobj = CytoscapeWidget()
cytoscapeobj.set_tooltip_source('name')
cytoscapeobj.graph.add_graph_from_df(df[:30], ['country'], ['age', 'virus'])
cytoscapeobj

They provide some installation tips here that might be helpful, including how to run tests locally.

[blois]

These should now be working in Colab, see https://github.com/googlecolab/colabtools/issues/498#issuecomment-916996133.

An example is https://colab.research.google.com/gist/blois/665fb53f06c09d6dd380b934eaea15f4/ipycytoscape.ipynb.

[blois]

To be clear- the goal has been to not have proprietary APIs but instead to work towards a common stable API that works in more environments.

If you try to install a different version of the package that is incompatible with the frontend assets

In our context there are no frontend assets at all. Aside from the minimal public API visualizations need to include all of their dependencies.

What I’m basically saying above is essentially a widget manager who’s API to the host is limited to just something along the lines of https://github.com/Quansight-Labs/jupyter-output-spec, then either loading that before the custom widget (initiated by user code), or just bundling that with the custom widget in a standalone binary which would have to be >800K.

In my view the widget manager and widget are tightly coupled due to the significant API surface area of widgets and their requirement of a common build tool (when using webpack’s module federation), thus they should be distributed together. Colab already uses a widget manager per cell execution using browser broadcast channels to coordinate, I don’t think it would be impossible to do a widget manager per widget? Then just include some esbuild created binary of the standalone binary in the widget cookie cutter and be free of the versioning issues? (I’m sure I’m oversimplifying here). We had hoped 1) to get consensus on the stable APIs necessary to support this so it could be used by other hosts and 2) to have a more minimal API to remove that large binary size.