Binderhub: Clarify that people should not share their personal binder links

[choldgraf]

We keep running into people that try to share their kubernetes pod link, rather than the "binder link" they should be sharing. How can we try to clear up this confusion? I've seen it enough times that I think it's worth having some kind of a solution for.

Alternatively, it could be that the UI changes @ellisonbg suggested where the shareable link is shown automatically will solve this.

Thoughts?

[minrk]

I think this goes back to the question of what does binderhub deploy. Lots of modifications to the environment make sense (share link, whitelabel headers, custom error handling, extensions, etc.), but we can never do any of these as long as we support custom Dockerfiles.

[ellisonbg]

I think the UI changes are a good start, but maybe there is a way to have
an extension inside the hosted notebook/jupyterlab that also provides the
URL to share.

On Wed, Oct 4, 2017 at 7:00 AM, Min RK [e-mail] wrote:

I think this goes back to the question of what does binderhub deploy. Lots
of modifications to the environment make sense (share link, whitelabel
headers, custom error handling, extensions, etc.), but we can never do any
of these as long as we support custom Dockerfiles.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/binderhub/issues/160#issuecomment-334164927,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0HqA4qSEd88lowhl4u012oSHOzIuks5so4-bgaJpZM4Ptika
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[choldgraf]

I think that's a good idea!

[yuvipanda]

Note that any notebook extensions won't work for repositories that use
their own dockerfile, and it's quite difficult to try to inject notebook
extensions into those.

On Wed, Oct 4, 2017 at 10:19 AM, Chris Holdgraf [e-mail]
wrote:

I think that's a good idea!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/binderhub/issues/160#issuecomment-334227110,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23vyNea_K_Hc-e9XsL_tKRL5WKibxks5so74fgaJpZM4Ptika
.

--
Yuvi Panda T
http://yuvi.in/blog

[choldgraf]

Do you think that needs to be a blocker though? It seem like there are a lot of features we can include only if people don't use a Dockerfile. Since we prefer people not to do this anyway, we can always include statements to the effect of "if you need to use your own Dockerfile, be warned that some features may not be enabled for you"

[minrk]

@choldgraf good point. It can be an incentive to avoid Dockerfiles. It does mean that any such features have to be relatively minor niceties, and not things that are relied upon for Binder to work.

[willingc]

Documentation (and perhaps a UI element popup or help text) should have a table that indicates what minimal functionality you receive when using a custom Dockerfile and what additional features/niceties are available if a custom Dockerfile is not used. Along with a nice note encouraging changing away from a custom Dockerfile if you would like the additional features.

[betatim]

With #459 now in place we can start working on adding this. See in particular https://github.com/jupyterhub/binderhub/pull/459#issuecomment-366695212