Docker-stacks: Bad ergonomics with CLI URL output

[anatoliykmetyuk]

On jupyter/tensorflow-notebook, when launching it, the terminal is supposed to output the URL to which I should navigate to access the notebook. Currently, it outputs:

http://(f844870a601a or 127.0.0.1):8888/?token=9ef73cf92a2b71ea5656ba2090e7301550c502ee99dcc5bf

Previously, it output:

http://127.0.0.1:8888/?token=9ef73cf92a2b71ea5656ba2090e7301550c502ee99dcc5bf

With the previous output, I could CMD+Click on the URL from iTerm2 to open the browser fast. With the new output, I can't do so, since the output does not present a valid URL. Copy-pasting takes more time and reduces ergonomics.

[parente]

Thanks for the report. This issue is a duplicate of #642 which includes a discussion about the upstream change in jupyter/notebook (https://github.com/jupyter/notebook/issues/3605), documentation that was updated here to account for this change, and the behavior of containers.

Reusing @minrk' summary: In general, the URL has never been valid because the container doesn't know the external port or ip. It happened to be right if you did the following:

• run docker locally (no docker-machine, etc.)
• forward the same port (8888:8888), never map different ports

Unfortunately, it's impossible for the container to know if either of these is the case, so the only reliable information that should be copied is the ?token=... part of the URL when the notebook is run in a container.

If you have a suggestion for how to improve this part of the UX, please do open a PR against jupyter/notebook. Quite a few people have raised this concern, but no one has a great answer to displaying a URL that works in all environments where the notebook runs.

[anatoliykmetyuk]

Ok, I see. One option could be to specify the URL with an environmental variable or a flag. The advantage of an envvar is that you can specify it once in docker-compose or elsewhere and benefit from a nice URL output each time you run the container.

[minrk]

If you set NotebookApp.custom_display_url = 'http://127.0.0.1:12345' then you can set the display URL to be copied. But unfortunately, the server in docker cannot know the URL unless the user launching the container tells it. If there's anything to do in docker-stacks, I think it would be to allow this to be set via an environment variable in addition to the cli flag.

[anatoliykmetyuk]

@minrk where do I set this?

[minrk]

CLI as --NotebookApp.custom_display_url or a config file as c.NotebookApp.custom_display_url. For instance, I right now have docker running in a minikube vm, so localhost can't work. With custom_display_url I can make the echoed URL one that will actually work via copy/paste:

eval $(minikube docker-env)
docker run --rm -it -p9999:8888 jupyter notebook --NotebookApp.custom_display_url=http://$(minikube ip):9999

or for docker-machine in general:

eval $(docker-machine env some-machine)
docker run --rm -it -p9999:8888 jupyter notebook --NotebookApp.custom_display_url=http://$(docker-machine ip some-machine):9999

Supporting setting this via env in the docker-stacks would be sensible, and potentially slightly more convenient in certain circumstances.

[anatoliykmetyuk]

Is there any way to set this parameter via ~/.jupyter/nbconfig/notebook.json file? I tried writing the following there:

{
  "NotebookApp": {
    "custom_display_url": "http://localhost:8888"
  }
}

But it did not work.

[minrk]

You can set it in a config file, just not that particular one, which is for configuring notebook javascript application. That exact JSON in ~/.jupyter/jupyter_notebook_config.json should work, though, or c.NotebookApp.custom_display_url = "http://localhost:8888" for the equivalent config in ~/.jupyter/jupyter_notebook_config.py.

[anatoliykmetyuk]

Thank you @minrk, it worked!

[w-c]

This seems to be addressed by https://github.com/jupyter/notebook/pull/4103.

[javabrett]

I agree this looks fixed in https://github.com/jupyter/notebook/pull/4103 , change which is unreleased as-of today. Not sure what the close-policy here, but this could be closed pending upstream-release and uptake here.

[parente]

Thanks for triaging. I agree we can close as the fix is upstream and workarounds are documented here in the meantime.