Latest scipy-notebook:lab-3.1.18 docker image actually contains lab 3.2.0

[carlosefr]

The latest docker image for jupyter/scipy-notebook:lab-3.1.18 does not contain Jupyter Lab 3.1.18, but 3.2.0. This is an issue if one needs to stay on 3.1.x for some reason.

What docker image you are using?

jupyter/scipy-notebook:lab-3.1.18, specifically jupyter/scipy-notebook@sha256:4aa1a2cc3126d490c8c6a5505c534623176327ddafdba1efbb4ac52e8dd05e81

What complete docker command do you run to launch the container (omitting sensitive values)?

docker run --rm -ti jupyter/scipy-notebook:lab-3.1.18 jupyter --version | grep lab

What do you expect to happen?

The Jupyter Lab version should be 3.1.18, as per the docker tag.

What actually happens?

The Jupyter Lab version is 3.2.0.

[mathbunnyru]

This is the corresponding build: https://github.com/jupyter/docker-stacks/runs/3915506220?check_suite_focus=true

Right now I have no ideas why this could have happened.

[mathbunnyru]

I think I know the reason for this.

Unfortunately, because of our complicated build system, we end up compiling images twice.
It's easy to see that pushing takes a lot of time.
Actually, the process looks like this:

1. Build.
2. Tag.
3. Push (but unfortunately, we also build here).

That's why we might end up in a situation like this.
I have checked both minimal and base images with the same tag.
And though they should be ancestors, it's not true.

[mathbunnyru]

@consideRatio any ideas, how to fix this?

I do actually have one, but I'm nor sure people will like it.
Do not build real multi-images.
Instead, use -arm suffix tag for arm based images.

This way, we will achieve many things simultaneously:

1. Faster build times - we can have two separate jobs, one for arm, another one for amd64.
2. Reducing complexity. Although we will have to add another type of complexity, but I think it will be much easier.
3. Images will be cached during one build process, because they won't take so much space.
4. Test arm images.
5. We can actually have correct tags and manifests for arm images as well.

[consideRatio]

If we use a suffix, it should be arm64 as arm often is used to represent arm32.

Hmmmm, it would absolutely reduce complexity quite significantly in this project, and that is important because it is shouldering a lot of complexity that is hard to maintain. At the same time, I know I'd have to do some work in jupyterhub/zero-to-jupyterhub-k8s to compensate if we have platform suffixes and such.

Ideally I'd like this complexity to be retained within this project, but with sufficient justification we must absolutely also be able to stop handling such complexity.

Perhaps ideally, we would platform separate builds, then have these, then have these be coalesced into a common image in my mind.

This discussion is very very relevant to #1407 in general. I'm too low on time to provide a time investment to refactor the build system at the moment, and would prefer if we don't abandon the current single-tag -> multi platform system, but I'm very appreciative of an idea to have it happen in steps instead, where we first build individual platforms and then coalesce them without rebuilding them for example.

Yikes, I'm not able to continue this discussion at the moment, too much work. =/

[ykazakov]

This happens also for other images: jupyter/minimal-notebook:hub-1.5.0 contains jupyterhub 2.0.0, not 1.5.0:

% docker run -it jupyter/minimal-notebook:hub-1.5.0 jupyterhub --version
2.0.0

I wonder if this is because this image was pushed (and possibly built again) on 17 of December 2021, after jupyterhub 2.0.0 was released on conda. Looking at docker commands for building the image, I do not see how a particular version of jupyterhub or jupyterlab is fixed in the image. Here is the command that was used to install them:

RUN |5 NB_USER=jovyan NB_UID=1000 NB_GID=100 PYTHON_VERSION=default CONDA_MIRROR=https://github.com/conda-forge/miniforge/releases/latest/download /bin/bash -o pipefail -c mamba install --quiet --yes     'notebook'     'jupyterhub'     'jupyterlab' &&     mamba clean --all -f -y &&     npm cache clean --force &&     jupyter notebook --generate-config &&     jupyter lab clean &&     rm -rf "/home/${NB_USER}/.cache/yarn" &&     fix-permissions "${CONDA_DIR}" &&     fix-permissions "/home/${NB_USER}" # buildkit

[ykazakov]

B.t.w., for the minimal image the lab version is also incorrect:

docker run -it jupyter/minimal-notebook:lab-3.1.18 jupyter lab --version
3.2.0

[carlosefr]

Just noticed that the jupyter/scipy-notebook:lab-3.2.9 image actually contains Jupyter Lab 3.3.0. If the version in the image tag can't be trusted, it may be a better idea not to tag images with a specific version at all.

Also, jupyter/scipy-notebook:lab-3.3.1 actually contains Jupyter Lab 3.3.2.

[avihaybar]

I've seen this happen in other images too -
jupyter/minimal-notebook:python-3.9.12 is actually python 3.9.13, while
jupyter/minimal-notebook:python-3.9.13 is actually python 3.10.