Create some extension points for notebook / cell execution

[choldgraf]

Description

I think that it would be useful if developers could piggy-back on nbclient and extend its functionality. At the simplest level, I think it'd be useful to have pre and post execution hooks when executing notebooks, where you could access the notebook/cell before and after the nbclient execution.

Benefit

I think that this would be beneficial for a few reason:

• At a strategic level, the Jupyter Project puts a strong emphasis on extensibility and modularity. This would bring these values into the nbclient project as well.
• It would allow people to experiment with programmatic execution of notebooks more effectively, without the high-stakes decision of modifying nbclient's core

An example where I think this would be useful is in this forum discussion about in-line markdown execution. If it were possible to extend nbclient in the ways described here, I think that somebody could prototype an in-line markdown execution functionality by creating a package that extends nbclient. (e.g., you could use a pre-execution hook that does something like "if it's a markdown cell, look for in-line execution syntax, if it exists then execute it with the kernel and append the mime-bundle to the markdown cell's metadata).

Implementation

I'm not sure the best place to implement this, but curious first if others would find the functionality useful.

Another possibility is that this would live in a similar package like papermill. In my mind this seems close enough to Jupyter's "core goals" that it'd be best as lightweight extension points in the core package, but I'd be open to arguments the other way!

[fperez]

I agree with the above, and it mimics the hooks we had from very early on into the kernel itself. Today that is managed by an events system that allows users to do things on pre/post execution of code blocks, for example (the old hooks from yonder still exist but are mostly deprecated in favor of the more flexible and less intrusive events system).

Obviously markdown cells don't even go to the kernel, so the above system wouldn't apply to the markdown part of notebooks, but I think the symmetry makes sense.

I also agree that generically this is a good idea that we use extensively in the project, for new directions to be explored more easily without forcing all decisions to be implemented in the core, shipped-by-default systems (which makes maintenance even harder than it already is).

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/inline-variable-insertion-in-markdown/10525/45

[davidbrochart]

Just for reference, something along these lines was started in #79, but never finished.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/inline-variable-insertion-in-markdown/10525/76