Repo2docker: Move this repository to the `jupyterhub` account?

Created on 11 Feb 2018  Â·  18Comments  Â·  Source: jupyterhub/repo2docker

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 ?

enhancement

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:

  • [ ] update .travis.yml config triggers for deploy.on.repo
  • [ ] maybe update travis config, if secret values are lost after migration? Not sure if that will happen.
  • [ ] checking for links to the github repo in the docs, which is also low-impact, since there will be a redirect in place already.
  • [ ] update henchbot with new repo url

All 18 comments

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/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

—
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:

  • [ ] move dockerhub image to new name
  • [ ] update travis deploy scripts to push to new location on docker hub
  • [ ] update helm chart to pull from new dockerhub location

    • [ ] binderhub chart

    • [ ] mybidner.org deployment meta chart

  • [ ] check the docs don't mention the image/repo location

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:

  • [ ] update .travis.yml config triggers for deploy.on.repo
  • [ ] maybe update travis config, if secret values are lost after migration? Not sure if that will happen.
  • [ ] checking for links to the github repo in the docs, which is also low-impact, since there will be a redirect in place already.
  • [ ] update henchbot with new repo url

I 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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Morisset picture Morisset  Â·  5Comments

jburos picture jburos  Â·  5Comments

NHDaly picture NHDaly  Â·  6Comments

minrk picture minrk  Â·  6Comments

nuest picture nuest  Â·  5Comments