-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI for building the environments #78
Comments
cc @trungleduc @atrawog @SylvainCorlay who may be interested in this discussion |
Pinging @yuvipanda, @consideRatio, and @GeorgianaElena who may be interested in this discussion, @jtpio 😉 |
Sorry this got lost in github. This is super exciting, @jtpio! As you know I'm a huge fan of tljh-repo2docker. We explored basing off that to begin with, but instead choose to go the binderhub route. I think expanding the UI that tljh-repo2docker has to work on z2jh has well would be excellent and extremely valuble to a lot of communities! binderhub can work without kubernetes (https://github.com/jupyterhub/binderhub/tree/main/testing/local-binder-local-hub for example), so it can work well with tljh too. There's also now a published binderhub API client. I'd love to find ways to collaborate with Quanstack and you on this. What do you think would be a useful next step? A sync meeting to explore options? |
Just noting that this is something the Binder community has discussed a few times and generally there's been a lot of enthusiasm for this. The last time I can remember, we discussed it in these issues:
I think I even had a little ipywidgets demo of this back in the day In particular I think that CodeOcean (linked in the issue) has roughly the workflow that I had in mind. They also use JupyterLab components (though I believe their system is all proprietary), so may be good to look towards for inspiration. |
I think this is actually quite different from the linked to repo2docker / binderhub issues, as that's about managing the source of the environment itself, while this is more about managing built environments. I think the original announcement of tljh-repo2docker (https://discourse.jupyter.org/t/a-tljh-plugin-to-build-user-environments-with-repo2docker/4258) has screenshots illustrating this quite nicely. |
Oops - disregard my comment in that case, I must have misunderstood it. Was just trying to provide some helpful breadcrumbs 🙂 Though I'd still check out the code ocean UI workflow because it includes a kind of end to end workflow for defining, building, and selecting environments |
Thanks for the replies!
Yeah I was thinking about joining one of the upcoming JupyterHub meetings to discuss this, but the next one may be challenging time-wise. So we could indeed have a sync-meetings to discuss ideas, and then report here or in different issues? Would next week for you? For example Monday 19 February? I guess 8-9 am Pacific time would work best? I looked a bit more into
|
@jtpio I am off on the 19th. Can we do 22nd? I can do 8-9am (although ofc 9am-10am is much better, but may be super difficult for you) pacific then. |
@jtpio yes, we'll need to port the UI for building the profile list, and it needs to be stored somewhere. I suspect a lot of what you currently have can be reused. The list can be dynamically populated - |
I think 22nd 9am-10am should work 👍 |
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-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
andtljh-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:
tljh-repo2docker
UI 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-repo2docker
work with both TLJH and ZTJHtljh-repo2docker
may in fact be able to reuse thebinderhub
package 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-repo2docker
could be converted to usebinderhub
for 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!
The text was updated successfully, but these errors were encountered: