Support cross-widget messaging

[kylebarron]

As of 0.2.1, juypter-ui-poll only overrides the post_run_cell IPython event. This means that execute_request is only patched after a cell is run. If you try to link two widgets together, jupyter-ui-poll is no longer activated for cross-widget messages because UI actions are generated from the post_execute event. Patching execute_request for post_execute seems to allow cross-widget synchronous messaging to work.

[Kirill888]

Thanks @kylebarron, change looks fine to me. Do you mind sharing an example notebook to verify functionality? Or better yet add linked widget section to notebooks/Examples

[Kirill888]

@kylebarron this change breaks Run All functionality as it no longer delays execution of cells until after current cell is done. Can you please provide more details about the failure mode you are experiencing? Version of libraries, what works what doesn't work, that sort of thing.

[kylebarron]

Sorry my week has been packed 😕. The tl;dr is that in https://docs.unfolded.ai/map-sdk-v1/setup-guide we're trying to use jupyter-ui-poll as a way to implement blocking communication in widgets between Python and JavaScript using custom widget messages. In this example notebook, we try to link a Plotly FigureWidget to our map, so that when you create a selection in the plotly map, it will filter the data in our map and vice versa. Specifically, we attach a callback to the Plotly histogram to call a method in our map to update the bounds of the filter. In unfolded.map-sdk version 1.3.0, before I vendored this PR fix, doing this would end up blocking kernel communication, because without overriding post_execute, jupyter-ui-poll would not be invoked in this case because no cell is being run. Rather, Python calls are only being made as a result of the callbacks attached on UI elements. This PR seemed to fix some elements of cross-widget communication because it doesn't need a cell to be run.

I know these aren't reproducible examples; I'll try to come up with something reproducible soon.

[Kirill888]

Looks like post_execute is a more generic callback that fires for "cell executions" as well as "non-interactive execute requests" (silent=True version). Since we currently delay execution of ALL execute_requests we should really register post_execute and not post_run_cell.

Question is this however: should we delay execution of "non-interactive" requests at all, not sure when these are used and by what libraries, or should we only delay actual cell executions only (would require inspecting requests).

Probably best way forward here is to just replace post_run_cell->post_execute, @kylebarron can you modify your PR to only register post_execute and not post_run_cell, then I'll merge.

[kylebarron]

Sorry I forgot to take out post_run_cell on this PR

[Kirill888]

@kylebarron no worries, I made a new release with your fix and some other minor tweaks, if you can check if that works for you that would be great.