Javascript error in containerized notebook: Model class 'RemoteFrameBufferModel' from module 'jupyter_rfb' is loaded but can not be instantiated

[vncntprvst]

Hi, I'm working on a Jupyter notebook that runs on a container, and calls to jupyter_rfb returns an error that looks similar to #58, but I haven't been able to pinpoint whether this is a package version issue or something else. Here's the error message:

Model class 'RemoteFrameBufferModel' from module 'jupyter_rfb' is loaded but can not be instantiated
_make_model@http://127.0.0.1:8888/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/150.b0e841b75317744a7595.js?v=b0e841b75317744a7595:1:7933

More discussion on the issue is available on the container's repo. Tagging @kushalkolar who is helping solve this issue.

Below are the versions for some of the packages installed in the container's environment:

ipywidgets                7.7.3              pyhd8ed1ab_0    conda-forge
jupyter-rfb               0.3.2                    pypi_0    pypi
jupyter_server            2.3.0              pyhd8ed1ab_0    conda-forge
jupyterlab                3.6.1              pyhd8ed1ab_0    conda-forge
jupyterlab_server         2.19.0             pyhd8ed1ab_0    conda-forge
jupyterlab_widgets        1.1.1              pyhd8ed1ab_0    conda-forge
notebook                  6.5.2              pyha770c72_1    conda-forge

Any idea?

Thanks!

[vncntprvst]

Using a working conda environment as a template to create the container's environment leads to the same error, or similar, e.g.:

Failed to load model class 'RemoteFrameBufferModel' from module 'jupyter_rfb'
loadClass@http://127.0.0.1:1234/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/134.40eaa5b8e976096d50b2.js?v=40eaa5b8e976096d50b2:1:74856
loadModelClass@http://127.0.0.1:1234/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/150.b0e841b75317744a7595.js?v=b0e841b75317744a7595:1:10729
_make_model@http://127.0.0.1:1234/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/150.b0e841b75317744a7595.js?v=b0e841b75317744a7595:1:7517
new_model@http://127.0.0.1:1234/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/150.b0e841b75317744a7595.js?v=b0e841b75317744a7595:1:5137
handle_comm_open@http://127.0.0.1:1234/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/150.b0e841b75317744a7595.js?v=b0e841b75317744a7595:1:3894
134/v/this._handleCommOpen@http://127.0.0.1:1234/lab/extensions/@jupyter-widgets/jupyterlab-manager/static/134.40eaa5b8e976096d50b2.js?v=40eaa5b8e976096d50b2:1:73393
_handleCommOpen@http://127.0.0.1:1234/static/lab/jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:1037310

There are issues, like this one, posted online, with no obvious solution. Any suggestions welcome. Thanks.

[almarklein]

I'd definitely start by trying jupyter_rfb version 0.3.3, because that contains the fix for #58.

[vncntprvst]

Thanks for getting back to me and making this suggestion. It didn't solve this specific issue but it's partially resolved anyway, at least as far as jupyter-rfb is concerned. Looks like package version conflicts between the notebook environment and the jupyterlab server running on the container created the problem. I'll post more details on the issue linked in the first post.

[kushalkolar]

I think it'd be useful to post here too, containerized apps is a really good use case for jupyter_rfb!

On Thu, Mar 2, 2023, 14:04 Vincent Prevosto @.***> wrote:

Closed #68 https://github.com/vispy/jupyter_rfb/issues/68 as completed.

— Reply to this email directly, view it on GitHub https://github.com/vispy/jupyter_rfb/issues/68#event-8652767246, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACHXXRCCC5VCATI435L2PKLW2DVKNANCNFSM6AAAAAAVMIIHYI . You are receiving this because you were mentioned.Message ID: @.***>

[vncntprvst]

Sounds good. So, to give a bit of background, the intended use of containers in this repository is to provide data analysis and visualization pipelines - typically as jupyter notebooks - to our lab's researchers. No installation needed, they just log in on their browser to the Jupyterhub server, and select which container they want to run from the drop-down menu on the splash screen. All the containers are built from a base image that matches the Jupyterhub server version, e.g. jupyter/tensorflow-notebook:hub-3.1.1. That determines what versions of jupyter server and jupyterlab run on that container. In addition, I often create (a) conda environment(s) that will be taylored to the notebooks' purpose. Some containers will have multiple environments, especially if they are intended for tutorials / demos. This is what I did here and where the problem emerged. In particular, the Jupyterlab versions between the base environment and the created environment (called caiman) were not the same, and that seemed to affect how well ipywidgets worked.
I used this small sample code as a test unit (borrowed from this SO thread):

from ipywidgets import interact

@interact(x=(0, 100, 10))
def p(x=50):
    pass

To pinpoint which package version could work together, I first used an older image (lab-3.1.18) and installed the environment with python 3.9 and ipywidgets 7.6.5, without installing anything else in it. In that case, the Jupyterlab instance is 3.1.18, and the ipywidgets unit test above works both in base and caiman. Installing fastplotlib (the package that calls jupyter-rfb) in the environment also works, but installing mesmerize-core fails. Now, the problem is, moving on to more recent Jupyterlab versions (I picked lab-3.5.3 as this was the version I used in a working mesmerize environment), installing packages in the environment while creating the Docker image vs installing them in a running Jupyterlab instance does not produce the same result. The latter works, while the former fails: the notebook container runs, but the unit test above does not - let alone jupyter-rfb. I played with pinning the environment's package versions (especially jupyterlab) but that prevented mesmerize-core installation. In the end, the simple solution is just to install packages directly in the base environment. Yep. Just for completion, the current working environment has these package versions:

fastplotlib               0.1.0a8                  pypi_0    pypi
ipywidgets                7.7.3                    pypi_0    pypi
jupyter-rfb               0.3.3                    pypi_0    pypi
jupyterlab                3.5.3              pyhd8ed1ab_0    conda-forge
mesmerize-core            0.2.0              pyhd8ed1ab_0    conda-forge

[almarklein]

Thanks for the details!