The latest release of ContainDS (0.2.6) has some small but important changes to the way Jupyter containers are handled.
Pull before Configuring
A Docker image on Docker Hub may contain important configuration information which is unavailable to ContainDS until after it is pulled to the local machine. This might inform ContainDS about the correct way to instantiate the container – for example, if it was created using Binder, it would need to be run in a particular way, and this caused problems in previous versions.
In version 0.2.6, ContainDS will wait until the Docker image has been fetched before prompting the user to configure it (select workspace etc). This also means there is an improved UI for launching non-Jupyter containers.
A container requiring configuration after downloading its underlying image will appear in the ‘Pending’ group:
New Jupyter Info Banner
Jupyter-based containers are now clearly marked and described in their Home tab:
There is a separate ‘Launch Jupyter in Browser’ link which performs the same function as the WEB button.
For Integrated Workspaces, there is an EXTRACT WORKSPACE button. This will obtain a copy of the /home/jovyan (or /home/jovyan/work) folder and files into a newly-created folder in your Downloads folder.
As ever, your feedback is really important to the future of this project. Please get in touch with any thoughts or questions at all.
Going forward, the intention is to experiment further with workspaces. If possible, the concept of Integrated Workspaces will be phased out. This would work if all Jupyter images can have their /home/jovyan contents spun out into locally-mounted workspaces. Images created through Binder from a GitHub repo naturally contain integrated workspaces, but with some creativity it should be possible to always extract the workspace files before running a new container based on the image.
It would be important to streamline the user interface here. One possibility is to specify a global working folder in ContainDS preferences, allowing ContainDS the freedom to create new folders within that for workspaces without having to prompt the user explicitly whenever new containers are created. For flexibility, a facility to rename or relocate the workspace folders would be useful in that scenario.
Most likely, this approach to workspaces would mean that all Jupyter images (including those from Jupyter’s docker-stacks) could have their workspaces rooted at /home/jovyan instead of /home/jovyan/work since any existing files at the /home/jovyan level should be extracted into the newly-mounted hard drive workspace.