Hi all.
I am currently trying to integrate a custom repoprovider into the UI.
Extending the js code seems not to be trivial as the predefined repo providers are hard coded.
So question: what is the philosophy: should the default binder ui be extensible (i.e. is collaboration with upstream wanted) or is the UI considered as “config” and should be written from scratch in such a case?
1 Like
Right now the list is indeed hard coded, which is not perfect. There is a PR that aims at making this more flexible https://github.com/jupyterhub/binderhub/pull/1038
I think the main reason why things are the way they are is that so far there has not been any demand for having custom and private repo providers. So someone wants to deploy their own BinderHub, add a repo provider and not upstream it. If that is a need/demand for this we should try and move https://github.com/jupyterhub/binderhub/pull/1038 forwards and see what else needs changing/could be improved.
Depending on what your repo provider does and what kinds of repos it covers I think we’d be interested in having it upstream. Maybe the test for “upstream or not?” could be “will it work on mybinder.org?”
The next “building site” for custom/configurable repo providers is repo2docker which needs to have a repo provider that matches the one in the UI. I’ve not tried to add a custom repo provider to a deployed BinderHub but I could imagine it requires a bit of acrobatics around keeping BinderHub and repo2docker in sync/configured consistently.
A potential end goal could be to have BinderHub interrogate the repo2docker version it has available to find out what repo providers it supports and then automagically configure its UI based on this. This would remove a lot of duplication, but I haven’t thought about it long enough to know what the downsides would be.
Summary: if your repo provider is usable by the general public we should talk about upstreaming it. If not we’d love some help to make the experience around using custom repo providers better.
Hey Tim
Thanks for your answer!
We are developing a LocalRepoProvider to launch from local repos (mounted via some NAS).
The idea is to provide to researchers a lab instance where there can work on their repos on a NAS folder without the need of a gitlab instance.
I am not sure if that will work on mybinder, but I could imagine, it would also be interesting for other people.
Anyway, we also have another repo provider in mind, which would be too special to be relevant for upstream.
In this sense, also the PR you mentioned would be interesting for us.
I think the local repo provider would already be weird to use on mybinder.org, so I agree we need to work on making it easier to have custom repo providers.
The quickest way to move things forward is for you to get involved. I don’t know off the top of my head where the PR stands or what else needs to be done on top. I’ll probably not have time to look at and think about this until some time next week (and who knows what will be next week 
) so if you have the time to help shepherd things along that would be great.
Hi @betatim
I was looking for docs on how to add a custom repoprovider (and probably an accompanying repo2docker content provider – I found this question and also noted that the PR you mentioned has been merged.
Is it now possible to add custom repoproviders (non git and so needs an accompanying repo2docker content provider?) to a binderhub installation via configuraiton files?