Most of the work in repo2docker happens in the jupyterhub account. Now that we have a nifty JupyterHub cauldron page, it'd be nice if repo2docker were a part of the same org so we can track activity here too.
WDYT @yuvipanda ?
it's generally useful outside of just JupyterHub, but I don't have strong
opinions either way.
On Sun, Feb 11, 2018 at 8:43 AM, Chris Holdgraf notifications@github.com
wrote:
Most of the work in repo2docker happens in the jupyterhub account. Now
that we have a nifty JupyterHub cauldron page
https://cauldron.io/dashboards/jupyterhub, it'd be nice if repo2docker
were a part of the same org so we can track activity here too.WDYT @yuvipanda https://github.com/yuvipanda ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/repo2docker/issues/232, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23vi2JRwRer_yf6_j7YQs9v_d43K7ks5tTxifgaJpZM4SBZ7g
.
--
Yuvi Panda T
http://yuvi.in/blog
I agree that from a "what does this repo do" standpoint, it could be useful outside of jupyterhub...from my perspective this is purely from a pragmatic standpoint to make it easier to track activity across the repos that broadly make up the JupyterHub ecosystem.
Do other folks have thoughts on this? @betatim @minrk or @willingc ?
alternatively, can somebody make a 'cauldron' out of the jupyter org?
While it's technically useful outside jupyterhub, I think the question is more about what is this intended for/etc. i.e. is it a generic package for any possible repo->docker Jupyter application? Or is it really driven by Binder's needs, and a separate component.
So if it's first a generic tool that Binder happens to use, then it belongs on jupyter. If it's first Binder's implementation that's reusable outside Binder, then I think it belongs on jupyterhub.
configurable-http-proxy is an example - it is the proxy we wrote for jupyterhub, so it lives there. That doesn't mean it's only useful for jupyterhub, but that's the target application.
So I'm +0.5 to putting it on jupyterhub, but ultimately the distinctions should be communicated in the repo and its docs, rather than based on where it lives. Where it lives is just one signal.
It sounds like we have lots of +0.5s here, so I am inclined to close this and do nothing, as in general I think we should tend towards not rockin' the boat unless there's a clear reason to do so...
If it's first Binder's implementation that's reusable outside Binder, then I think it belongs on jupyterhub.
I lean toward moving it to JupyterHub. Currently, it's primary use is for Binder. While it could be used outside of Binder, it's not clear to me this is happening now. For efficiency and monitoring it, it may be better served in the JupyterHub org. Jupyter tends to have more protocol definition, notebook ui, and user facing things (i.e. website).
Having it in one org would also keep users deploying their own binderhubs from having to bounce back and forth between orgs.
Overall, I'm fine with leaving as is, but long-term it may be better served in the jupyterhub org.
FWIW I agree with @willingc :-)
so it sounds like we're at roughly
+.5 - @yuvipanda @minrk
+1 - @willingc @choldgraf
I do find myself just naturally looking for the repo2docker repository under github.com/jupyterhub...the number of times I get an error the nhave to go back and delete the hub is fairly high haha
Currently the docker image lives at 'jupyter/repo2docker' so if this gets
moved that should be moved (and all relevant places updated) too. JFYI. I'm
decidely a +0, only because my autocomplete takes me to
github.com/jupyterhub/repo2docker but that already redirects here ;)
On Mon, Feb 12, 2018 at 8:58 AM, Chris Holdgraf notifications@github.com
wrote:
FWIW I agree with @willingc https://github.com/willingc :-)
so it sounds like we're at roughly
+.5 - @yuvipanda https://github.com/yuvipanda @minrk
https://github.com/minrk
+1 - @willingc https://github.com/willingc @choldgraf
https://github.com/choldgrafI do find myself just naturally looking for the repo2docker repository
under github.com/jupyterhub...the number of times I get an error the
nhave to go back and delete the hub is fairly high haha—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/repo2docker/issues/232#issuecomment-364988563,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23hrfOmuRysssq8aysBVBH5rODhX8ks5tUG2rgaJpZM4SBZ7g
.
--
Yuvi Panda T
http://yuvi.in/blog
I'm a +1 for the move on the basis of its intended purpose and scope matching juptyerhub (and deployment on Docker containers) more closely than it does generic jupyter utilities.
My two cents: I don't care enough to do the clean up work this would require. If someone else feels like doing it that would be Ok with me :)
what are the things we'd need to do in order for this to live in JupyterHub? Would it require changing a lotta code?
(feel free to edit this list as new things come up)
Things to do if we move:
considering the fact that @betatim's list is a bit sizeable, and since nobody feels _super_ strongly about moving the repo, I'm gonna close this issue since it doesn't seem something we need to act on soon. If somebody disagrees, feel free to re-open the issue!
Reopening this related to recent discussions regarding adoption of repos in the jupyterhub org (https://github.com/jupyterhub/team-compass/issues/315 , https://github.com/jupyterhub/team-compass/issues/313).
I will note that we don't need to update the dockerhub image to move the repo, which is the source of most of the friction. It's not a requirement that docker hub repos must match github ones. Since updating the image is the most costly part, I'd vote for moving the repo back to jupyterhub, but leaving the docker image alone. That leaves only these tasks:
deploy.on.repoI LIKE IT
update: added henchbot to task list
I'm definitely +1 on this, this conceptually trips me up every time I navigate to the r2d repo :-)
I wish we had moved this years ago to jupyterhub org. Going forward it makes good sense. Thanks!
Most helpful comment
Reopening this related to recent discussions regarding adoption of repos in the jupyterhub org (https://github.com/jupyterhub/team-compass/issues/315 , https://github.com/jupyterhub/team-compass/issues/313).
I will note that we don't need to update the dockerhub image to move the repo, which is the source of most of the friction. It's not a requirement that docker hub repos must match github ones. Since updating the image is the most costly part, I'd vote for moving the repo back to jupyterhub, but leaving the docker image alone. That leaves only these tasks:
deploy.on.repo