Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Importing workspaces shouldn't need base_url set #5977

Closed
yuvipanda opened this issue Feb 11, 2019 · 6 comments · Fixed by #6473
Closed

Importing workspaces shouldn't need base_url set #5977

yuvipanda opened this issue Feb 11, 2019 · 6 comments · Fixed by #6473

Comments

@yuvipanda
Copy link
Contributor

@yuvipanda yuvipanda commented Feb 11, 2019

Importing workspaces requires base_url to be set, with something like:

https://github.com/fperez/eclib/blob/f2ad849c585e71ddb16d0520cc00416bac6b00e6/binder/start#L4

This causes problems when running on JupyterHub.

  1. Often, the same environment is built for many users. This means there would be one virtualenv or conda env (one sys.prefix) with many individual users with their own base_url. These users might not have persistent ${HOME} either. Thus, one workspace file might need to work for 'em all
  2. base_url is not guaranteed to be the same across multiple logins for the same user - they can be changed pretty easily. If using named servers on JupyterHub, they will change whenever the user starts a new name.
  3. When building containers for use, you will do a 'build' once - when you don't know the base_url and then run it each time for many users. This breaks that.

In general, base_url should be considered a 'runtime parameter' while (in my mind) workspaces are a build time parameter, and mixing runtime parameters in build places breaks JupyterHub.

@yuvipanda
Copy link
Contributor Author

@yuvipanda yuvipanda commented Feb 11, 2019

This also breaks all repo2docker based builds, like jupyterhub/repo2docker#578

@bollwyvl
Copy link
Contributor

@bollwyvl bollwyvl commented Feb 11, 2019

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Feb 21, 2019

@afshin Can you weigh in on how feasible it would be to remove the base_url from the workspace ID and have it just rely on the workspace name?

@yuvipanda
Copy link
Contributor Author

@yuvipanda yuvipanda commented Feb 21, 2019

You can also have base_url be interpolated at runtime in your client or server code - this is what jupyter-server-proxy does, for example. '{base_url}' is replaced by the actual base_url at runtime...

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Feb 21, 2019

We have base_url available in the lab client code (it is used pretty prolifically to construct requests to the server). @afshin included it as part of the workspace for a reason that I can no longer remember...

@lock
Copy link

@lock lock bot commented Aug 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants