Test TM351 container in codespace
This repo demonstrates settings for running an OU built Docker container inside Github Codespace.
Create a workspace:
On first creating the workspace, the TM351 Docker image will be downloaded and a container spawned from it.
By default, the environment opens into a VS Code editor (is there a way of changing that via a config setting so that it opens in JupyerLab?)
For some reason, something changes, and I get prompted to rebuild:
(I'm not sure if this is due to some cruft that has been cached from a previous session?)
Notebooks can be opened using the default VSCode editor.
I keep seeming to hit inconsistent behaviour trying to connect to the kernel.
When deleting and relaunching the workspace, I often seem to get:
Which then rebuilds things - but I don't see what has supposedly changed? Or is this just a UI issue with the Github homepage and I need to refresh the homepage after any changes to the repo???
I'm not sure if I have to forward the port?
The TM351 notebook should be running as http://localhost:8888?token=letmein.
The notebook server seems to take some time to start. Sometimes (I'm not sure under what conditions), it seems to be announced:
To connect to the URL, search on conn in the VS Code command palette to find the Jupyter: Connect to remote URL setting.
Then paste in the above URL.
You should then be able to connect to the Python 3 (ipykernel)(Remote) Jupyter kernel*.
NOTE: at other times, I seem to be able to connect just to Python 3 (ipykernel), eg if I restart the workspace. There is something going on in the plumbing, almost as if the kernel is picked up by default, but not the token? It would be useful to be able to set up the kernel URL connection etc in a .devcontainer settings file.
Displaying the notebook homepage (or JupyterLab UI) via the forwarded port 8888 seems to work okay, but I can't seem to open a new notebook (which also seems to knock the environment over):
If I stop the workspace, and then restart/repopen it, I looks like I can reopen it into a JupyterLab UI rather than the VS Code UI (can I pre-install extensions into th JupyterLab UI via a settings file?)
Or not:
Try again, this time with the codespace running from the previoulsy failed attempt to open it in JupyterLab:
Hmmm... I notice that the server extensions have been picked up (Open Refine and nbsearch).
And they run:
And the correct kernel seems to be available; for example, the databases are connecting fine...
But then I try again...
And OpenRefine breaks too...
At this point, I get the feeling that this is not really viable - the current setup/recipe above seems a bit fraught and hacky, but we can get to a working JupyterLab instance. It'd be nice to have a robust set of instructions that work reliably, and also to find a way customise the JupyerLab environment (or is it somehow picking up the JupyterLab environment in the container???). I'm also not sure I've got a good model of how the CodeSpace actually works...