This looks great - thank you for sharing! It has some things in common with my Repo2DockerSpawner. You’ve managed to simplify a lot of the process, and make the build part admin-only whereas mine worked directly as a version of DockerSpawner where the user can specify their own Binder-ready repo URLs whenever they make a new server. It probably makes sense in most cases for the available Binders to be admin-controlled as they are in tljh-repo2docker.
Anyway, the most enlightening thing is that I am now aware that there is such a thing as a TLJH plugin!
To what extent does that plugin system need to be tied to TLJH (as opposed to JupyterHub in general)? I’ve taken a look but maybe failed to fully understand what the plugins are allowed to do…
I have essentially built a JupyterHub plugin in my ContainDS Dashboards project. As you can see in the Installation instructions, the way it fits into JupyterHub is through manual jupyterhub_config.py imports from my package: template_paths, tornado_settings, and extra_handlers.
And then optionally template_vars - plus some requirements around how you configure DockerSpawner and allow_named_servers…
The extension overrides some of the core JupyterHub templates too, injecting its own UI into specific places (e.g. an extra section on the home.html page).
Setting these multiple entrypoints works, assuming an otherwise plain JH configuration… but certainly it would cause problems if you also installed a similar extension that had its own ideas about how these entrypoints should be extended.
I think my approach is very different to what you mean by a ‘plugin’ here, but it would be interesting to know if there is any overlap in the long term vision…
Standardising some of what I’ve tried to do could allow multiple extensions to co-exist without conflict.