Context
Thanks for putting this repo together!
Just stumbled on the related blog post today, which seems to be announcing the project a bit more officially: https://2i2c.org/blog/2024/jupyterhub-binderhub-gesis/
The blog post mentions the following sentence:
A pre-selected list of environments (container images), provided by the administrators who set up this JupyterHub
Which leads to the following question: is there also a UI that administrators can use to pre-build these environments? Or are there plans to make one?
A while ago I opened this topic on Discourse to ask this question, which led to this binderhub-service repo on GitHub: https://discourse.jupyter.org/t/ui-for-building-ztjh-ready-images-with-repo2docker-binderhub/22610.
The reason I'm asking is because we have recently been looking updating the existing tljh-repo2docker plugin to make it more modular, and also work with ZTJH deployments. And initiated some work to revamp the UI for building environments (the UI is only available to JupyterHub administrators).
In the end, it looks like both binderhub-service and tljh-repo2docker may have quite a bit of overlap.
So this issue is mostly to get an idea whether the maintainers of this binderhub-service repo would be interested in having a UI to pre-build images (even as opt-in), and potentially join efforts.
Proposal
At QuantStack we currently have some funding to:
- Work on revamping the
tljh-repo2docker UI with a modern stack, and so the plugin can be installed as a JupyterHub service instead of the current use of c.JupyterHub.extra_handlers:
- Make
tljh-repo2docker work with both TLJH and ZTJH
Updates and actions
Maybe a first step could be to check if tljh-repo2docker could be converted to use binderhub for its backend (or the same stack as used here in binderhub-service). And make it possible to install the UI separately easily, so it could still be used in TLJH but also now in ZTJH with binderhub-service.
Maybe this could be structured in a way it can be useful to multiple deployment scenarios (local hub, TLJH, ZTJH).
Let us know what you think, and if there might be some challenges for providing such UI. Thanks!
Context
Thanks for putting this repo together!
Just stumbled on the related blog post today, which seems to be announcing the project a bit more officially: https://2i2c.org/blog/2024/jupyterhub-binderhub-gesis/
The blog post mentions the following sentence:
Which leads to the following question: is there also a UI that administrators can use to pre-build these environments? Or are there plans to make one?
A while ago I opened this topic on Discourse to ask this question, which led to this
binderhub-servicerepo on GitHub: https://discourse.jupyter.org/t/ui-for-building-ztjh-ready-images-with-repo2docker-binderhub/22610.The reason I'm asking is because we have recently been looking updating the existing
tljh-repo2dockerplugin to make it more modular, and also work with ZTJH deployments. And initiated some work to revamp the UI for building environments (the UI is only available to JupyterHub administrators).In the end, it looks like both
binderhub-serviceandtljh-repo2dockermay have quite a bit of overlap.So this issue is mostly to get an idea whether the maintainers of this
binderhub-servicerepo would be interested in having a UI to pre-build images (even as opt-in), and potentially join efforts.Proposal
At QuantStack we currently have some funding to:
tljh-repo2dockerUI with a modern stack, and so the plugin can be installed as a JupyterHub service instead of the current use ofc.JupyterHub.extra_handlers:tljh-repo2dockerwork with both TLJH and ZTJHtljh-repo2dockermay in fact be able to reuse thebinderhubpackage directly for building the images. Building on the recent API mode addition: Allow building the image without needing to launch it jupyterhub/binderhub#1647Updates and actions
Maybe a first step could be to check if
tljh-repo2dockercould be converted to usebinderhubfor its backend (or the same stack as used here inbinderhub-service). And make it possible to install the UI separately easily, so it could still be used in TLJH but also now in ZTJH withbinderhub-service.Maybe this could be structured in a way it can be useful to multiple deployment scenarios (local hub, TLJH, ZTJH).
Let us know what you think, and if there might be some challenges for providing such UI. Thanks!