Dockerizable as Jupyter Downstream?

[jimdelois]

Are there any working examples of using this library in a Docker container downstream of the enormously-popular and nearly-defacto Jupyter stacks?

Would it be possible to document how to do this?

• xeus-octave version: 0.2.0 on Octave 8.4.0
• Operating System: Docker - FROM jupyter/datascience-notebook

Description

Describe what you were trying to get done:

I was trying to create a Docker image using xeus-octave as a downstream of a Jupyter stack image.

Tell us what happened, what went wrong, and what you expected to happen:

I tried following various instructions from the suggestions of other GH Issues that report related issues in this repo. What I expected was that one of the randomly suggested (but untested) configurations would work. What happened was that not a single recommendation worked.

What I Did

I did many things. The most-straightforward, as advised by contributor comments, was that I created the file ./container/octave-kernel.json as:

{
  "display_name": "Octave (xeus-octave)",
  "argv": [
    "/usr/bin/xvfb-run",
    "-a",
    "/opt/conda/bin/xoctave",
    "-f",
    "{connection_file}"
  ],
  "language": "Octave",
  "metadata": {
    "debugger": false
  }
}

Thence,

FROM jupyter/datascience-notebook

USER root

RUN apt-get update && \
    apt-get install -y octave libzmq3-dev gnuplot-qt xvfb && \
    apt-get autoclean && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

USER $NB_UID

RUN mamba install -y xeus-octave

COPY ./container/octave-kernel.json /opt/conda/share/jupyter/kernels/xoctave/kernel.json

# I would prefer not to have to specify this, but in an attempt to get xoctave to work, we adopt this pattern
CMD ["xvfb-run", "-a", "start-notebook.py"]

I tried about ten or so different CMD versions, from all of the available Jupyter-supplied wrapper scripts (preferred) all the way down to just CMD ["xvfb-run", "jupyter", "lab"] (not preferred). In any configuration I could think up, the Octave kernel would still just crash.

Each configuration would typically yield a different error message in the console, but the most common one was generally of the form:

lab-1  | [I 2024-09-10 01:15:48.103 ServerApp] Kernel started: 1266c2ff-acbe-49dc-b21b-0d0af33d51d0
lab-1  | Instantiating kernel
lab-1  | Core instantiated
lab-1  | error: XDG_RUNTIME_DIR is invalid or not set in the environment.
lab-1  | terminate called after throwing an instance of 'octave::execution_exception'
lab-1  |   what():  feval: function 'graphics_toolkit' not found
lab-1  | Aborted