REST API for executing cells in a notebook

JupyterLab
, ,
1

Hey all,

We are using JupyterHub / Lab for remote code execution in our service.

I am looking for a REST API for executing arbitrary cells in a notebook, something like the “Restart Kernel and Run All Cells…” button in the notebook toolbar

Thanks :pray:

2

It’s unclear what actor this is asking to run the cell:

  • a Jupyter Kernel, e.g ipykernel, with a fully-managed lifecycle
  • a Jupyter Client, e.g. jupyterlab, with an ad-hoc lifecycle

For the former, one can use:

If one would expect a client to actually be doing this on your behalf, the closest thing I know of (disclaimer: author) is jyg, which is barely more than a prototype. But it does offer a REST API which would allow running the run all cells command, given a browser is (and stays) open.

2 Likes
3

Hey bollwyvl,
Thank you for you answer :pray:
You rightfully deduced the actor is a Jupyter Client

We have a “browserless” server application that manages user sessions via JupyterHub REST Api.
When we have a running user server we use @jupyterlab/services typescript SDK to interact with the server and execute some code.

Since servers can start cold, we want to have all previous execution context ready before executing the next code block, hence we want to “execute all previous code blocks”.

We are currently using the execute_request to execute code, but if I understand correctly this API directly executes code on the kernel and does not interact with any persistent file.

I would like to have something that is more like a notebook, meaning, when the user requests to execute code, we add the code as a new cell in the notebook and then run all cells sequentially (if needed).

I’m wondering what is the recommended approach here?
Is there an API for interacting with a notebook / cells?
Should we us the contents API to read/update the contents of some notebook and use the kernel to execute it manually?

Thank you so much for your help
Kfir

4

At the protocol level, a kernel doesn’t know anything about a notebook document. The exceptions:

  • the kernel process is started with the cwd of the folder holding the notebook
  • some clients provide the cellId in the metadata of some requests, and some kernels do something with it
  • but as metadata, this is not propagated back on replies from the kernel

So without a full client in the loop, your custom client would need to:

  • parse the document itself
  • find all the code cells
  • punch them into the kernel
  • remember which cell goes with which message id
  • put them into the correct place
  • write back to the contents manager

With a standard client in the loop, this becomes… a lot more complicated, as the state of the truth of the document can become out-of-sync.

There has been discussion on jupyter_server of some this… perhaps the Thursday call would be a space to raise more of these concerns and questions.

2 Likes