Requirements for tree file path navigation

JupyterLab
1

I am trying to use a common lisp kernel installed on a docker image:

notalinkhttps://mybinder.org/v2/gh/andreasplesch/common-lisp-jupyter/dockerstack?urlpath=lab/

It generally works well.

Here is the Dockerfile:

notalinkhttps://github.com/andreasplesch/common-lisp-jupyter/blob/446cf562c09d452082bed81ab52866529eb61290/Dockerfile

I am trying to use the tree navigation feature to launch a specific notebook directly:

JupyterLab starts but does not load the notebook.

Is the path relative to the HOME directory, or the Docker WORKDIR directory before launching lab ? [Answer: the last WORKDIR from Docker]

also does not load the notebook.

What does JupyterLab expect to use and have available when it encounter such a tree urlpath ? [Answer: it looks like an initialized, default workspace is expected]

Thanks. -Andreas

PS: sorry for the notalinks due to a restriction of discourse.

2

Hi Andreas,

Your dockerfile approach is resulting in a version of JupyterLab that is more recent than the version that binder currently uses. If you launch JupyterLab from the current example, you’ll note the version that comes up from there lacks the little icons in the bottom left corner you see when you launch yours.

If you want to use a more recent version there is a way to start it off upon launch with a specific notebook directly. In fact the bottom of the JupyterLab Binder example points a more recent version of JupyterLab that runs on Binder. The JupyterLab Demo repo includes in the binder directory a file spelling out a workspace in json. The last line of the postBuild in that directory tells jupyterlab to import that workspace and so when it starts you launch with a specific notebook on the left and a panel with a webpage form the documentation open on the right. Workspaces can be made more simpler. I have one that currently just opens the index page at this repo. And there too postBuild is used to import it.

Here and here cover it more.

The simplest way I have found to make the workspace is to launch into a repo Binder and get the view the way I want and then in a terminal window run jupyter lab workspaces export . But I think this only works when you have a workspace already set-up, at least when launching on Binder. I just tried it in yours after bring up a notebook and everything is blank, confirming my view that expoert doesn’t help initially. The longer way that seems to work no matter what get is to first get the path the the workspaces by running in a terminal jupyter lab path. Then cd to the Workspaces directory , look at the contents using ls, and cat labworkspace.. file. Then I copy that to my new workspace.json file and edit the id info right near the end to just read '"id": "/lab".

However, this is all where methods other than a Dockerfile is being used by docker2repo to make the build form the repo. I think that besides making the json file, you can probably add an equivalent line to your Dockerfile like the one that is used in postBuild (or sometimes I have seen the same line in start) pointing at that json to import it. The caveat being that use of a Dockerfile is kind of the most adventurous path, and so YMMV.

3

Thanks for your extensive response. I think the thought (by the original authors of the lisp/maxima jupyter kernel) for using a Dockerfile was that the setup is too different from the standard setup, and perhaps also that it is easier to understand and control than the many layers of repo2docker. Also, apparently it was initially difficult the get the common lisp engines to work on Ubuntu, Arch was preferred.

The JupterLab version we use is just the one inherited from the minimal notebook docker image from jupyter stacks itself, so it should be the same as in the examples. I did notice that the Running Terminals and Kernels icon differs (a walking person versus a square in a circle). Perhaps that icon depends on the kernel ?

Is there a log file somewhere to see if jupyterlab has problems with urlpath ? Perhaps logging needs to be activated. It looks like there is a config option: {'LabApp': {'log_level': 10} (Does a config file overwrite the existing config or is it merged in? Probably just a replacement).

I saw the workspaces configuration in the documentation and may give it a try. It should be just a matter of adding the jupyter lab workspaces import .. line to the Dockerfile instead, and setting up the json config as you described.

4

~/.jupyter/lab/workspaces
has autocreated workspace configs. For example:

{"data":{
  "layout-restorer:data":{
     "main":{
        "dock":{
           "type":"tab-area",
           "currentIndex":2,
           "widgets":[
              "notebook:about.ipynb",
               "terminal:1"
            ]
        },
        "mode":"multiple-document",
        "current":"terminal:1"},
        "left":{
           "collapsed":false,
           "current":"filebrowser",
           "widgets":[
              "filebrowser",
              "running-sessions",
              "command-palette",
              "tab-manager"
           ]
        },
        "right":{
          "collapsed":true,
          "widgets":[]
        }
     },
     "terminal:1":{
       "data":{
         "name":"1"
       }
   },
   "notebook:about.ipynb":{
     "data":{
       "path":"about.ipynb",
       "factory":"Notebook"
     }
   }
 },
 "metadata":{
   "id":"/lab/workspaces/auto-F"
 }
}

A bit strange to have keys without values in the widgets arrays.

This also gets report by
$ jupyter lab workspaces export auto-F
where auto-F is the workspace name. The name seems to be part of the filename of the config file, and is in the id metadata key.

https://jupyterlab.readthedocs.io/en/latest/user/urls.html#managing-workspaces-cli

is the brief doc on workspaces.

5

Using workspaces to define a default layout including an open notebook worked fine. I just had to make sure that the config json was available to the docker build.

It still would be very useful to use urlpaths to point to a notebook since this does not require rebuilding the docker image.

Oh, that does work now, too: Binder

It looks like something got initialized by importing a workspace as a default workspace. What could that be ?

That leaves my other question about having to restart the kernel to make widgets render properly:

Perhaps the ipywidgets github issues is a better place for this question.

1 Like
6

Hm, the exact same Dockerfile stopped now working after a rebuild. The workspace json is available but not used as the default workspace.
Did jupyterlab change ?

7

Just tried it and it opened with about.ipynb like it seems it should. Maybe just bad launch the other day?