This entirely mimics the mybinder.org user interface at the moment so should be familiar.
ContainDS itself is designed to be an app for easily managing Jupyter environments running locally through Docker, but without needing to learn Docker itself. As well as launching environments via Binder, you can select one of the standard Jupyter Docker images. ContainDS takes care of mounting a workspace folder form your hard drive, and launching Jupyter Lab or Notebooks without needing to copy and paste tokens. Since the images are Linux-based, some packages will be easier to install and be consistent across systems.
I would very much appreciate your feedback on the concept and on the software itself!
The Binder user interface could be extended to take advantage of being local (and not public as on mybinder.org) - for example, allowing git credentials to be entered for private repos. There are also UI features in the works that I might be able to offer back to mybinder.org - e.g. pasted URLs being automatically parsed into sensible UI defaults.
I hope this is a powerful new approach for the Binder world, and that you find it useful.
Yes. It does some custom logic itself, such as resolving the correct commit hash, then wraps up the image building process through the jupyter/repo2docker:0.10.0 Docker Hub image. Similar to mybinder.org really!
@danlester Via @betatim’s post on recent repo activity in various related repos, I note:
https://github.com/jupyterhub/binderhub/issues/1003The need for persistence — makes me think: when working with a local docker install and the containds client, you could mount a volume against the repo that files could be persisted in? Would then perhaps also require a switch that lets you delete the volume and mount a new one? I note also that a local dir can be mounted into the container, but in some cases you may want a volume that is purely local to the container and not exposed on the desktop, eg if you have imported some additional packages but don’t want to clone an image of the container do want to kill the container but retain the ability to mount the volume against a new container with the same name as the original?
@psychemedia thank you for thinking through these ideas. I think you are right that there are different scenarios where you might want to live mount the original local folder as your workspace, and others where you just want a copy of the files inside the container (an ‘integrated workspace’).
‘Local Folder’ is a new Binder option I’ve built into the latest release of ContainDS 0.2.3:
There is a checkbox for ‘Mount local folder as the workspace’.
I think this allows you to separate the two main scenarios, but needs a bit of thought if you decide to instantiate the cached images as new containers directly (through the Docker tab). I’ve built in some warnings/defaults to describe how this was configured at the time the image was created with Binder.
