kernel_spec_manager_class sometimes only works under ServerApp instead of JupyterApp in jupyter_config.json

[twrightsman]

Hello,

I've noticed an issue with Jupyter Lab finding kernels inside Conda environments using nb_conda_kernels on the managed notebooks on Google Cloud.

Here is the start of the server logs, if helpful:

Jul 12 20:13:40 twrightsman bash[414]: [W 2022-07-12 20:13:40.596 ServerApp] notebook_dir is deprecated, use root_dir
Jul 12 20:13:44 twrightsman bash[414]: [I 2022-07-12 20:13:44.912 ServerApp] beatrix_jupyterlab | extension was successfully linked.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.918 MathJaxExtension] Config option `kernel_spec_manager_class` not recognized by `MathJaxExtension`.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.921 MathJaxExtension] Config option `kernel_spec_manager_class` not recognized by `MathJaxExtension`.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.936 MathJaxExtension] Config option `kernel_spec_manager_class` not recognized by `MathJaxExtension`.
Jul 12 20:13:44 twrightsman bash[414]: [I 2022-07-12 20:13:44.940 ServerApp] jupyter_server_mathjax | extension was successfully linked.
Jul 12 20:13:44 twrightsman bash[414]: [I 2022-07-12 20:13:44.940 ServerApp] jupyter_server_proxy | extension was successfully linked.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.946 LabApp] Config option `kernel_spec_manager_class` not recognized by `LabApp`.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.958 LabApp] Config option `kernel_spec_manager_class` not recognized by `LabApp`.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.973 LabApp] Config option `kernel_spec_manager_class` not recognized by `LabApp`.
Jul 12 20:13:44 twrightsman bash[414]: [I 2022-07-12 20:13:44.975 ServerApp] jupyterlab | extension was successfully linked.
Jul 12 20:13:44 twrightsman bash[414]: [I 2022-07-12 20:13:44.975 ServerApp] jupyterlab_git | extension was successfully linked.
Jul 12 20:13:44 twrightsman bash[414]: [I 2022-07-12 20:13:44.975 ServerApp] jupytext | extension was successfully linked.
Jul 12 20:13:44 twrightsman bash[414]: [W 2022-07-12 20:13:44.979 NotebookApp] Config option `kernel_spec_manager_class` not recognized by `NotebookApp`.
Jul 12 20:13:45 twrightsman bash[414]: [W 2022-07-12 20:13:45.027 NotebookApp] Config option `kernel_spec_manager_class` not recognized by `NotebookApp`.
Jul 12 20:13:45 twrightsman bash[414]: [W 2022-07-12 20:13:45.045 NotebookApp] Config option `kernel_spec_manager_class` not recognized by `NotebookApp`.
Jul 12 20:13:45 twrightsman bash[414]: [I 2022-07-12 20:13:45.047 ServerApp] nbclassic | extension was successfully linked.
Jul 12 20:13:45 twrightsman bash[414]: [I 2022-07-12 20:13:45.047 ServerApp] nbdime | extension was successfully linked.
Jul 12 20:13:45 twrightsman bash[414]: [I 2022-07-12 20:13:45.108 ServerApp] nb_conda | extension was found and enabled by notebook_shim. Consider moving the extension to Jupyter Server's extension paths.
Jul 12 20:13:45 twrightsman bash[414]: [I 2022-07-12 20:13:45.108 ServerApp] nb_conda | extension was successfully linked.

The jupyter server version and verbose status output from nb_conda_kernels.install:

$ jupyter server --version
1.18.0
$ python -m nb_conda_kernels.install --status --verbose
Determining the status of nb_conda_kernels...
CONDA_PREFIX: /opt/conda
Entry points:
  - conda = nb_conda_kernels.discovery:CondaKernelProvider
  NOTE: entry points not used in Jupyter 7.3.4
Configuration files:
  - /etc/jupyter: <no files>
  - /usr/local/etc/jupyter: <no files>
  * $CONDA_PREFIX/etc/jupyter:
      jupyter_config.json: {
          "JupyterApp": {
            "kernel_spec_manager_class": "nb_conda_kernels.CondaKernelSpecManager"
          }
        }
      jupyter_notebook_config.json: {
          "NotebookApp": {
            "nbserver_extensions": {
              "nb_conda": true,
              "jupyter_http_over_ws": true
            }
          }
        }
  - ~/.local/etc/jupyter: <no files>
  - ~/.jupyter: <no files>
Status: enabled

I noticed that if I change the "JupyterApp" key in "$CONDA_PREFIX/etc/jupyter" to "ServerApp" and restart the server then the kernels in other environments are detected by Jupyter Lab, even if the extension is disabled (which it seems to revert to on server restart).

$ python -m nb_conda_kernels.install --status --verbose
Determining the status of nb_conda_kernels...
CONDA_PREFIX: /opt/conda
Entry points:
  - conda = nb_conda_kernels.discovery:CondaKernelProvider
  NOTE: entry points not used in Jupyter 7.3.4
Configuration files:
  - /etc/jupyter: <no files>
  - /usr/local/etc/jupyter: <no files>
  * $CONDA_PREFIX/etc/jupyter:
      jupyter_config.json: {
          "ServerApp": {
            "kernel_spec_manager_class": "nb_conda_kernels.CondaKernelSpecManager"
          }
        }
      jupyter_notebook_config.json: {
          "NotebookApp": {
            "nbserver_extensions": {
              "nb_conda": true,
              "jupyter_http_over_ws": true
            }
          }
        }
  - ~/.local/etc/jupyter: <no files>
  - ~/.jupyter: <no files>
Status: disabled

I unfortunately can't reproduce this on my personal laptop with fresh Conda installs of Jupyter Lab and nb_conda_kernels, the "JupyterLab" key works and I can discover kernels in other Conda environments. So I'm a bit lost at what might be occurring in the managed Jupyter environment...