What would a repo2docker GUI look like?

feedback

#1

repo2docker is the tool that is used to build the images on mybinder.org. The philosophy behind its design is to reuse files that people already place in their repositories anyway. To keep the effort for making your repository reproducible as small as possible.

Now there are a lot of repositories that run on mybinder.org, which means you could also run them locally with repo2docker. This means that a great way to get started with a new project is to copy an existing repo in that area and use their setup for repo2docker to get a nice environment that is ready to go.

If there was going to be a GUI for repo2docker, what would it look like? Would it be useful to integrate with nteract.io?

Maybe a different way of asking this question is: is anyone actually using repo2docker locally?


#2

I feel like mybinder.org practically is the repo2docker gui, so a local version would logically take a pretty similar form. The main inputs are the same:

  1. repo (a local gui would presumably support a local path, unlike mybinder.org), and
  2. a ref. With local repos, at least, you could have a ref picker/browser, since getting all branches/tags would be simple.
  3. file/url to open

The repo2docker CLI has lots more inputs than exposed in binderhub (image name, build resource restrictions, etc.). A GUI doesn’t need to expose every option, though. If desired, these could have their own ‘advanced’ controls, or more simply have a bulk extra args field to type arbitrary additional cli args.


#3

I like the idea of starting from something similar to mybinder.org’s landing page.

For local repositories it would be cool if we could have a “Open with repo2docker” for folders that are have a high potential to work (would have to define how we figure that out). Allowing people to double click a repo that will run.

Been pondering if it should offer a graphical way to author environment.yml/install.R files or not. Would be useful but also potentially quite fiddly. Maybe a better starting point is to expose postBuild and start in a way that makes them more discoverable. It fees like right now if you have a problem that start can solve (say “I need environment variables set”) there isn’t a really good way to navigate to the solution export FOO=bar from a place where you only know what it is you want to do.

Another thing for v2 would be a “popular on mybinder,org today” based on the metrics we publish. Helping with exploration of the ecosystem.


#4

One question I have here: I like the idea of tightly-scoping repo2docker around what it does now: builds a docker image from a repository. When you mention adding a GUI, do you mean:

  • adding a GUI for repo2docker in BinderHub? Or do you mean:
  • building in the ability for repo2docker to serve webpages w/ an interface that funnels back to the repo2docker mechanism?

If it’s the former, perhaps we could re-name this title to “What would a BinderHub GUI for repo2docker look like?”

Another option is that this could actually be a totally separate project from either of these two things. A simple web-app that does 1 thing, which is "serve a web page with a GUI on it that adds a collection of files to a folder for subsequent building w/ a tool like repo2docker.


#5

Lowering the bar for using repo2docker locally and making its (more exotic) features easier to discover is what I am thinking of with “a GUI for repo2docker”. Something like an electron app that lets you drive repo2docker in a way that doesn’t involve the CLI. Ever.

The motivation being that I want to increase adoption of repo2docker (more precisely the way it lets you specify environments by using already existing file formats, the “repo2docker way”?) as a way to share complicated to setup environments with others. Imagine you are a research group where each new member needs to get up and running with a whole stack of tools that is tricky to setup. Why not maintain a repository that serves as the cookie cutter for that and uses repo2docker to create the environment?

There are a lot of people who aren’t into using the CLI as a way to discover a new tool and would find it easier to get started if there was a GUI. I learnt a lot about Latex by using Lyx (and eventually looking at the code it generated for me).


#6

From a user’s perspective, I am totally on-board with the idea, my question pertains more to “where does that tech live?”. Adding a GUI layer to repo2docker would make it a different kind of technology…I’m trying to figure out if this GUI layer makes sense as a part of repo2docker, as a part of BinderHub, or as a different repo/app/etc altogether.

It sounds like we don’t want this to be a part of BinderHub, since running a BinderHub locally would not make repo2docker more accessible for most people.


#7

IMHO making it easier to run thing on r2d locally using a GUI doesn’t solve most of the problem of actually running things locally on r2d. My personal opinion is getting the configuration files right is the hardest part regardless of what interface it is. I realize this is slightly tangential- but what I mean to say is I think we could make a plugin for something like nteract or atom or something like that but that’s not how I currently use r2d. Based on my experience the hardest things with r2d is how to get the configurations right so it builds and how to run r2d on whatever cloud service you want since we don’t have that documented.

FWIW I think the binder extension is a great way of handling this issue for now.


#8

Ah! I was thinking this would be totally separate as you can use repo2docker as a library or via its CLI. I don’t think there are many benefits to combining a Python library with a potentially JS application into one repository :slight_smile:


split this topic #9

A post was split to a new topic: The “mybinder.org, deconstructed” guide


#10

My intuition is the same as yours - I think it’d be great for this to be a separate app. Though ideally something that we could use as a part of something like jupyterhub/binderhub as well


split this topic #11

A post was merged into an existing topic: The “mybinder.org, deconstructed” guide


#12

Hmmm… thinks…bits of this discussion remind me of O’Reilly Launchbot: https://blog.ouseful.info/2017/08/30/oreilly-launchbot-like-a-personal-binder-app-for-running-jupyter-notebooks-and-other-containerised-browser-apps/


#13

ooh that’s interesting - first I’ve heard of it! Did your investigations into launchbot ever go anywhere?


#14

A brief email exchange, i think, but never got past the initial play (no access to the code, IIRC?).