Is there a jupyterlab scipy docker image/tag?

JupyterLab
1

According to Selecting an Image — docker-stacks latest documentation there are different packages for notebook , jupyterhub and jupyterlab - but I can’t find any information as to which tag might actually give me such an image? I tried the lab-3.2.3 tag on Docker Hub but that seems to be the same as the default/untagged image?

So far I’m using jupyter/scipy-notebook as base image, but I want to add jupyterlab_git and I understand this cannot be done in a “plain/old” notebook…

2

Docker(hub) is kind of a nightmare for finding out what’s actually in there. But the docker-stacks Dockerfiles on github are pretty well organized:

So base-notebook includes jupyterlab, therefore everything that inherits FROM it does as well.

For your sanity, you’ll likely want to follow that pattern, of using mamba (and cleaning up after it).

Instead of just jupyterlab, for your image, you’ll want to specify a particular jupyterlab==? version known to work with the version of jupyterlab-git you want. This will result in some size increase (your final image will actually contain two copies of the lab assets, etc) but is worth having slightly more control of what your end user actually sees.

1 Like
3

That’s the thing: I build my image with an extended version of this Dockerfile - it extends jupyter/scipy-notebook which in turn extends base-notebook. However, the container I get doesn’t run jupyterlab but the “old” notebook.

I do set

    environment:
      JUPYTER_ENABLE_LAB: 'yes'

in my compose, but the log says

[I 08:36:58.033 NotebookApp] Jupyter Notebook 6.4.5 is running at:

What am I missing here?

4

What command are you using to start the container?

From here:

Or, to run JupyterLab instead of the classic notebook, run the following:
docker run -it --rm -p 8888:8888 jupyter/base-notebook start.sh jupyter lab

What address are you using in your browser to access what is running on the server?
I may be wrong because I haven’t tried using these recently in docker; however, the documentation here says:

Visiting http://:10000/lab?token= in a browser loads JupyterLab,

Usually the URL allows you to switch between the interfaces on these containers that run multiple services. I use Binder a lot and this is the idea there.

5

Perfect, that was too simple :slight_smile:

6

That ‘QuickStart’ seems to be the only place featuring that in main documentation site and the ‘Quick Start’ at the main Github page lacks that information although it repeats most of it, see here.
Does that agree with what you found when you struggled?

If that is the case, I’m thinking the documentation could use featuring that better and also the two ‘Quick Start’ blurbs could be made consistent?

7

I think so, yes, although I suspect I came in through a side door in lack of finding a clear starting point :wink:

I can in fact install jupyterlab-git without specifying a distinct jupyterlab version, so my original problem is solved. However, I’ve tried some other extensions, some of which throw some dependency errors. So how do I pick a given version for jupyter lab? Are those indeed the lab-version tags as listed Docker hub?

1 Like
8

I’ve tried some other extensions, some of which throw some dependency errors

without more concrete information, it sounds like they may not be compatible with jupyterlab 3, in which case, who knows. while more pallatable than, say, on a windows machine, doing jupyter lab build or jupyter labextension install x is pretty much going to ruin your build well-clock time, reproducibility, and image size without a lot of careful trickery.

Are those indeed the lab-version tags as listed Docker hub?

The unfortunate thing is that tags on docker images mean… exactly what the author thinks they mean. It may mean, “had lab3.2.3 installed at some point” all the way up to “configured and tested to run lab-3.2.3” or … something in-between. As soon as you do anything to them, that tag might mean nothing.

Concretely, If you install other extensions, you might get an entirely new lab along with it. Or other things can change.

So, once again, it’s really going to be worth your time to:

  • with an environment.yml or similar, lock down the versions, exactly, of the things that are important to you
  • deploy your own overrides.json, jupyter_config.json, etc.
1 Like