JupyterLab - the default?

[consideRatio]

What we decide on to be the default matters a great deal. I think we should make it so that the default is to use jupyterlab.

Yay or nay?

[betatim]

I would wait until there is a none beta release of JupyterLab.

[choldgraf]

IMO we can also let the JupyterLab community guide us on this.

@ian-r-rose @jasongrout @ellisonbg it'd be great if, over time, y'all could give us ideas for when to start "defaulting" to jupyterlab.

[consideRatio]

Lab	Notebook	Me

[choldgraf]

lol that's amazing

[ellisonbg]

FWIW, as of JupyterLab 0.33, we have dropped the Beta label

…

On Tue, Jul 31, 2018 at 11:58 AM Chris Holdgraf ***@***.***> wrote: lol that's amazing — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#776 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0NoWZ1JKqIyxUp6ao0CSCTCJD2Wzks5uMKjkgaJpZM4VZqhq> .

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

[consideRatio]

Yaaaaaaaaaaaaaaaaaaay!!!!!

Well the base notebook that we are using as the default image for a z2jh deployment, got bumped YESTERDAY to JupyterLab 0.33!!!

I say let's do it!

[ellisonbg]

I should note that some functionality that cover feature parity with the classic notebook are in extensions right now. In the coming months many of those will be merged into the main distribution, but we may want to think about having a canonical set of extension that get installed.

…

On Wed, Aug 1, 2018 at 10:10 AM Erik Sundell ***@***.***> wrote: Yaaaaaaaaaaaaaaaaaaay!!!!! Well the base notebook that we are using as the default image for a z2jh deployment, got bumped YESTERDAY to JupyterLab 0.33 <jupyter/docker-stacks@2518154> !!! I say let's do it! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#776 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0JNnPoPecvFX0YlEkJm1W4SqOQI7ks5uMeDzgaJpZM4VZqhq> .

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

wow I didn't realize that beta would get dropped so soon. hmmm, in this case I am more open to JupyterLab by default.

My main question is: @ellisonbg and others, what's your main experience with "first timers" seeing JupyterLab? Are we at a point where there's enough good documentation out there that it doesn't scare people away w/ the extra complexity?

[ellisonbg]

My experience with JupyterLab first-timers is that the usability of lab is equal to or better than that of the classic notebook. My biggest source of data for this is that I have been teaching intro to Data Science in Python each winter quarter (about 60 students/year). I am with the students 6 hours a week, working with them all closely as they code. I had used classic for years and this past January (2018) used Lab. Using lab with year for the first time was very pleasant and, in a number of ways much better than classic. However, I should note that both lab and classic have ongoing usability problems that often tower over other improvements we have made: * Large outputs are still a complete pain - student generate those on a regular basis by putting print statements to debug nested for loops. * Large notebooks render slowly and are difficult to work with and navigate. * Running out of memory happens easily and has a horrible user experience. * Most commonly used actions on cells (run, delete, etc.) are not co-located in the cells. * No support for fully capable undo/redo. * ... As we have resources, we are tackling these and other usability problems in lab, so the situation should get better in the coming months. At the same time, we still hear from folks that "lab is more complex than classic." We have worked extremely hard on its design and have specifically worked to preserve the simplicity of the classic notebook. We would love to understand this perception, but haven't had the resources to do a formal study. Even though many individual UI elements in lab are simpler than in the classic notebook, I think there is something to these perceptions and am hopeful we can understand and address it. The user documentation in lab is in reasonably good shape, but in my experience, most first timers won't even get to the docs if they have a bad experience in getting started on their own. However, we have enough users of the classic notebook, I don't think there is any harm to introducing "lab as the default" slowly. One of the big lessons of the Python 2 -> 3 transition for me was "more carrot, less stick." I want people to switch to lab because there are so many great, cool things that they want to use it - not because we force them to.

…

On Wed, Aug 1, 2018 at 11:30 AM Chris Holdgraf ***@***.***> wrote: wow I didn't realize that beta would get dropped so soon. hmmm, in this case I am more open to JupyterLab by default. My main question is: @ellisonbg <https://github.com/ellisonbg> and others, what's your main experience with "first timers" seeing JupyterLab? Are we at a point where there's enough good documentation out there that it doesn't scare people away w/ the extra complexity? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#776 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0BP4P8evMoa4270KPfy8bzRu43GKks5uMfPfgaJpZM4VZqhq> .

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

[betatim]

One of the big lessons of the Python 2 -> 3 transition for me was "more carrot, less stick." I want people to switch to lab because there are so many great, cool things that they want to use it - not because we force them to.

Maybe we can start with making "change to using lab by default" a recommended first task/exercise for customising your hub. So either add it to https://zero-to-jupyterhub.readthedocs.io/en/latest/setup-jupyterhub.html or link to "change to lab" as the next step?

[consideRatio]

@betatim I like it! I think it will be a z2jh maintainer experience, setting something up without trouble and things just work (because it is just adding /lab to singleuser.defaultUrl I think).

@ellisonbg thanks for this write up! Getting such experience isn't easy, so I consider being able to pick up on your insights very valuable to me! By the way, regarding the horrible user experience of running out of memory - jupyterhub/kubespawner#223 (and duplicated on JupyterHub: jupyterhub/jupyterhub#2043)

[choldgraf]

I like the idea of making the documentation for this step more front-and-center. That's a nice compromise!

[gweis]

I think jupyterhub/kubespawner#149 is related as well.

[manics]

Any more thoughts .... should we handle this alongside jupyterhub/repo2docker#724 ?

[choldgraf]

I think that we could make the default different in Z2JH before we do it in repo2docker since it affects fewer users. That said, I am not sure what's the criteria that we should use to switch. Perhaps if we get some data saying that a majority of users prefer the JupyterLab interface to the notebook interface?

[ellisonbg]

At a minimum, I would wait until we have finished the work to make JupyterLab's single document mode a suitable replacement for the classic notebook style UI. We are aiming to have that in place for JLab 3.0 this summer.

…

On Thu, Jun 11, 2020 at 4:16 PM Chris Holdgraf ***@***.***> wrote: I think that we could make the default different in Z2JH before we do it in repo2docker since it affects fewer users. That said, I am not sure what's the criteria that we should use to switch. Perhaps if we get some data saying that a majority of users prefer the JupyterLab interface to the notebook interface? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#776 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUFAIK5NCTAOKBONSK3RWFQWVANCNFSM4FLGVBVA> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform ([email protected]) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[choldgraf]

@ellisonbg that is both

1. Very exciting to hear about the single document mode (will it be activate-able via the launch command? then that should be an easier switch for z2jh and binder)
2. Sounds like a good criteria for switching to me

[ellisonbg]

We are looking at having the improved single document mode included in the URL (maybe /sdm rather than /lab) so it would be possible to modify the `jupyter lab` command to direct the user there on launch

…

On Fri, Jun 12, 2020 at 8:02 AM Chris Holdgraf ***@***.***> wrote: @ellisonbg <https://github.com/ellisonbg> that is both 1. Very exciting to hear about the single document mode (will it be activate-able via the launch command? then that should be an easier switch for z2jh and binder) 2. Sounds like a good criteria for switching to me — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#776 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUDT2OSIKGBN5E2S35DRWI7RXANCNFSM4FLGVBVA> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform ([email protected]) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[choldgraf]

my understanding is that this issue is just about the default, not dropping support (which IMO would be a more drastic change than just changing the default)

[manics]

Definitely keeping both, and only changing the default.

Though I'm wondering if there's a nicer way to do this than

set singleuser.defaultUrl to /lab instead of / (and change the singleuser.cmd to jupyter-labhub ?).

Is there a way we can set the default in the singleuser image only, and have JupyterHub agnostic to the default?

[consideRatio]

Is there a way we can set the default in the singleuser image only, and have JupyterHub agnostic to the default?

I'm not sure, but I think the answer depends on various parts to consider.

• ServerApp / NotebookApp? Docker image dependent, as long as one is present any combination is viable I think.
• JupyterLab 2 or JupyterLab 3? Docker image dependent, but our sample image should come with JupyterLab 3 rather than 2.
• Startup script within Docker image:
  By installing JupyterHub, there are a few entrypoints installed by default.
  • jupyter-labhub comes from jupyterlab itself but not in version 2, only in v1 and v3.
  • start-singleuser.sh comes from jupyter/docker-stacks`

One example of a working configuration is to have:

# jupyter_server / ServerApp will be used i think
singleuser:
  cmd: start-singleuser.sh # z2jh default!
  defaultUrl: /lab
  extraEnv:
    JUPYTERHUB_SINGLEUSER_APP: jupyter_server.serverapp.ServerApp

I think another is...

# notebook / NotebookApp will be used will be used i think
singleuser:
  cmd: jupyter-labhub
  defaultUrl: /lab

[yuvipanda]

https://discourse.jupyter.org/t/poll-should-zero-to-jupyterhub-switch-to-jupyterlab-as-the-default-user-interface/8001 had 40 participants, and a 90% approval. I now suggest we:

• Write docs on how to switch back to classic notebook, and why you might do so
• Write bold bold letters in the changelog that this will change default behavior! And how you can get back the old one
• Figure out story for images that don't have JupyterLab installed
• Figure out story for images that only have JupyterLab 2.0 installed (it needs a different command)
• Make the switch

Thanks everyone for working on this :)

I don't think we should switch to jupyter-server yet though. One at a time?

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/poll-should-zero-to-jupyterhub-switch-to-jupyterlab-as-the-default-user-interface/8001/3

[manics]

JupyterLab 3 already requires jupyter-server. How would changing to JupyterLab but not jupyter-server differ from changing to both?

[yuvipanda]

I'm very confused about it too :) I think it's the process you start that makes a difference. Primarily, I don't know what effect running jupyter-server has on serverextensions, since those heavily import from the notebook package. And I'm guessing the nbclassic package has differences from what's offered in the notebook package.

[Zsailer]

@yuvipanda I don't know what effect running jupyter-server has on serverextensions,

A lot of work was done to make sure jupyter-server is backwards compatible with old extensions, i.e. that all old server extensions are automatically discovered by jupyter-server via nbclassic (jupyter/nbclassic#12). NBClassic must be installed/enabled for this to work; fortunately, JupyterLab depends on nbclassic. In theory, old server extensions should just work (famous last words).

nbclassic mirrors the classic notebook package. It actually depends on notebook and uses its JS assets for rendering the notebook. It forks the tornado handlers, but they are essentially the same at this point in time.

There is a list of PRs that still need porting between notebook and jupyter-server, so jupyter-server differs slightly from the classic notebook server in this way.

since those heavily import from the notebook package

Old server extensions do import from the notebook package—mostly just IPythonHandler—but they still work seamlessly with jupyter-server.

@manics How would changing to JupyterLab but not jupyter-server differ from changing to both?

JupyterLab 3.0's entrypoint uses jupyter-server's tornado server; it is possible to use the classic notebook server and add JupyterLab 3.0 to notebook's nbserver_extension list.

With JupyterLab 3.0 + jupyter-server, jupyterhub users would get:

1. JupyterLab 3.0 and it's sweet new federated extension mechanism
2. Notebook's UI (via nbclassic)
3. nbserver_extensions (via nbclassic) and jpserver_extensions (via jupyter_server)

[manics]

@yuvipanda Does the above comment deal with your concerns around switching to jupyter-server? If so we could default to jupyterlab and jupyter-server, release an RC with a big announcement on discourse asking people to test, and if there are no major issues after a month release Z2JH?

[yuvipanda]

I trust @Zsailer :D

[manics]

Do you think we could achieve this by working with the docker-stacks maintainers instead of overriding it in Z2JH?
https://discourse.jupyter.org/t/pyspark-library-is-missing-from-jupyter-pyspark-notebook-when-running-with-jupyterhub-zero-to-jupyterhub-k8s/8450
was caused by singleuser.cmd overriding the default start-notebook.sh. Setting singleuser.cmd = None (i.e. revert to the Docker image default) works with JupyterHub since start-notebook.sh detects when it's running under JupyterHub:
https://github.com/jupyter/docker-stacks/blob/3395de4db93ada5e8eb0fd7da70a1a32ce4b8381/base-notebook/start-notebook.sh#L12-L14

If for example the default in docker-stacks was jupyterlab then we could remove the singleuser.cmd override and everyting would just work ™

[parente]

👋 @manics jupyter/docker-stacks#1217 is a good place to chime in about changing the default in docker-stacks.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/how-to-define-spawner-args-with-a-dict-using-new-traitlets-format/8714/1

[manics]

JupyterHub 2 will be out soon, which means it might be time for Z2JH 2 😃. Shall we try and figure out something that works? If we can pass all the relevant options as environment variables that minimises breakage of other singleuser implementations.

[minrk]

I've realized that jupyterhub 2.0 is probably a good time to switch the default for jupyterhub itself as well jupyterhub/jupyterhub#3615

That means the default with jupyterhub 2.0 will be lab if z2jh does nothing. z2jh deployments can opt-in to the classic server with

singleuser:
  extraEnv:
    JUPYTERHUB_SINGLEUSER_APP: notebook.notebookapp.NotebookApp

Then zj2h doesn't need to do anything, and can rely on the defaults of the underlying implementation.

[minrk]

other valid configs:

lab default UI, but keep legacy server (this is what BinderHub does, but I think it's maybe not the right choice when it's easier for a deployment to specify its choice. Behavior should be less surprising if when you see jupyterlab, you get the behavior as similar as possible to a local jupyter lab):

singleuser:
  defaultUrl: '/lab'
  extraEnv:
    JUPYTERHUB_SINGLEUSER_APP: notebook.notebookapp.NotebookApp

server app, legacy UI default:

singleuser:
  defaultUrl: '/tree'
  extraEnv:
    JUPYTERHUB_SINGLEUSER_APP: jupyter_server.serverapp.ServerApp

[minrk]

or retrolab:

singleuser:
  defaultUrl: '/retro/'

  # below only required for jupyterhub 1.x, after https://github.com/jupyterhub/jupyterhub/pull/3615
  extraEnv:
    JUPYTERHUB_SINGLEUSER_APP: jupyter_server.serverapp.ServerApp

[minrk]

In general, most extension-based apps are simpler with ServerApp because you only need to:

1. install the extension in the image
2. enable the extension (usually installation does this already, so nothing to do here)
3. set the default URL to the extension prefix (/lab = jupyterlab, /retro = retrolab, /tree = nbclassic)

This works today if you set JUPYTERHUB_SINGLEUSER_APP=jupyter_server.serverapp.ServerApp in 1.3+ and 2.0b1, but that step is unnecessary after jupyterhub/jupyterhub#3615 .

Using extension apps as JUPYTERHUB_SINGLEUSER_APP should also work, but jupyterhub/jupyterhub#3617 makes it a little complicated. ExtensionApps also usually only do a couple of things:

1. set default url (can be done separately)
2. ensure the extension is enabled (avoids possible config issues where it could be disabled somehow, but usually not an issue)
3. expose different cli flags, which shouldn't usually be relevant to jupyterhub entrypoints

[minrk]

#2398 adds the above examples, and some explanation (too much?) about choices between servers and UIs. All the examples should work the same on JupyterHub 1.x and 2.x, regardless of the defaults.