Consider allowing multiple kernels in the same document.

[akhmerov]

Is your feature request related to a problem? Please describe.

Historically jupyter-sphinx implemented including the inputs and outputs of multiple notebooks within the same document. This was done before we had thebe integration. Thebe, on the other hand, assumes a correspondence 1 document = 1 kernel.

I would even consider removing this feature from jupyter-sphinx, however searching through github revealed multiple uses out in the wild, including one by @moorepants in pydy and one in kwant where I'm involved. These uses fall into two categories:

• Section of a document that are conceptually isolated, e.g. different topics or different exercises.
• Parts to be executed in different languages. This makes sense in a library that provides API in multiple languages. Can even be combined with tabs... :thinking:.

Both uses seem reasonable.

Describe the solution you'd like

I therefore propose to support running multiple kernels within the document. This may be ruled as being out of scope of thebe, but I think this warrants consideration. One possible implementation would be to label each thebe DOM element with the kernel id to which it belongs.

Describe alternatives you've considered

Not supporting multiple kernels in a single document :)

[choldgraf]

It seems like a reasonable feature to have, though it breaks with Jupyter's "one kernel per document" approach, and we generally default to "doing things like Jupyter" unless there's a clear reason to depart.

I think a big thing we should consider is extra maintenance and complexity burden. Thebe is operating with basically 0 resources right now, so whatever solution we come up with needs to be fairly simple and straightforward, and cannot involve a major change in the code.

[akhmerov]

I completely agree with the maintenance and engineering aspect. As I wrote in the description, I even considered disabling the feature completely until I saw that there are uses out in the wild. Labeling as "help wanted" based on that.

[joergbrech]

BTW, we have another use case, where we want to write a "Modeling and Simulation" jupyter-book for engineers. Currently the book uses a Matlab/Octave kernel and that is the main language taught in the course. But the language itself is not the main focus of the course. In the future, we would like to add Julia and Python as well and ideally have all the interactive code blocks multilingual. I was thinking of something along the lines of interactive tabbed content blocks.

[moorepants]

Possible duplicate of #79.