For a similar use case, I’ve been thinking of building ‘The Littlest Binder’ (maybe as a plugin to The Littlest JupyterHub). Note it says ‘Binder’ and not ‘BinderHub’ and that is intentional!
The idea is that you can set up a machine that’ll serve ephemeral sessions (similar to BinderHub) to anyone who joins, but of only one repository you set up. So if you have a single repository you wanna use for your workshop / talk, you can set up one VM with “The Littlest BinderHub” pointing to your repo, and give that link out to folks. When your workshop is done, you can tear it down. The links would no longer work (so you should also give them mybinder.org links!), but it gives you a lot more control and power than now.
I think this is useful in principle. To some degree, this is what tmpnb was already - given an image, serve anonymous instances. Add a call to repo2docker to build the image and you are there.
A quick clarification question - how would this be different from a tool that would run a bunch of system commands (assuming you’re on a linux machine perhaps) when given a repo that adhered to the repo2docker spec?
I think something like “repo2docker but without needing docker” would be pretty useful! Paired with a little bit of documentation that would basically be “the littlest binderhub” no?
I think what Yuvi is proposing is some syntactic sugar and pre-configured configuration that sets up a JupyterHub with NullAuthenticator and as part of the setup(?) runs repo2docker https://githost.com/myworkshop.git. A tmpnb cookie cutter?
Creating a version of repo2docker that doesn’t use any kind of container would be amazing but I think impossible, if you don’t allow VMs. A repo2container that is like r2d but doesn’t use the docker toolchain could be possible and exciting (no need for root), just a lot of work
I assume it would be tmpauthenticator and DockerSpawner to match the tmpnb behavior, since that would be simplest. I figured it would not be replicating repo2docker without docker.
I think this would also be a great exercise for the hooks @yuvipanda put into tljh to see if they are sufficient for this case.
Hi, wanted to put my two cents in on this thread as I’ve just had a meeting with @KirstieJane and we may have a use case!
We have a case study that we’d like to include in the Turing Way book which way exceeds the computational requirements mybinder.org provides (see this issue), so to get around this I built a bespoke BinderHub on a cluster with bigger VMs. While we want anyone who comes along to the Turing Way book to be able to run this case study on this new BinderHub, we don’t want them to be able to run any repo they like.
The littlest binder that just hosts one repo would be ideal! Or is there a way that I can lock down my current Hub to only build one repo from the config?
Y’all should check out a (what is I think undocumented) feature of BinderHub to ban repositories. This uses a regex, so I think you should be able to do something like “match anything that is not the repository you want to allow”
See here for where this is configured in mybinder.org:
We should definitely add this to the documentation. See here for an issue I just opened:
Been thinking again about a “littlest Binderhub” and how it might relate to a couple of contexts:
a class that provides several Jupyter Book books that each run against a different docker container;
electron wrapped courses as per the spacy course (ANN) (which in turn makes me wonder: electron wrapped Jupyter Book?)
In this case, it might be useful to have an easily installed Binderhub environment that can launch one or more containers in order to support a range of courses / books?
See also the discussion around snakestagram / custom conda envts for baking into nteract app.
I spent all day procrastinating on other important work I had to do, so here’s a demo of an instance of The Littlest Binder!
You can access it at http://34.74.126.139. I’ll probably keep that running for a few more days or so.
The core of this is a new repo2dockerspawner. Images are built if needed with repo2docker every time a user server starts. So if you are pointing to ‘master’ and it has new commits, new users will automatically.
There’s a lot of work left to do, but this is a good start. Soon enough, we can have a TLJH Plugin that turns it into The Littlest Binder. repo2dockerspawner probably has a lot of other single-node uses too.
So is this “just” a jupyterhub with a spawner that gives it the ability to launch a against a repo, rebuilding if necessary? So presumably the Jupyterhub landing page could also give a user a selection of several environments - named docker containers, git repos - from which they could launch a specific environment?
Yeah, DockerSpawner already lets you pick from a whitelist of images, so mapping these onto repos instead should be a pretty small change.
If you require the admin to build images beforehand rather than enabling builds as part of spawn, then the default DockerSpawner + image_whitelist should be all you need. It’s less automatic and therefore less “bindery” but might fit, depending on your needs.
And made me wonder… If I have binder directory with conda.yml file (for example), then it should be relatively to figure out what I’d need to put into an environment customisation plugin?
To what 
Them. Helps keep TLJH small and focused while allowing other cool things to build on top of it.