added troubleshooting message on build failure

[telamonian]

References

#6907 (comment)

Code changes

Wraps the build function in LabBuildApp in a try...except that will print a helpful troubleshooting message if the build fails.

User-facing changes

Users get a troubleshooting message if their build fails.

Backwards-incompatible changes

None

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[telamonian]

I don't have the part in the message about how to set up your config files for LabBuildApp correct yet. Adding the

c.LabBuildApp.minimize = False
c.LabBuildApp.dev_build = False

options in my .jupyter/jupyter_notebook_config.py doesn't seem to do anything. Is LabBuildApp set up to properly consume options from config files? Or is there something else I'm missing?

Also, is there a better approach to printing the message on build failure then just wrapping build in a try...except?

[blink1073]

The approach seems reasonable. I'm not sure off the top of my head why the config wouldn't work.

[vidartf]

I agree some more details could be useful for resolving OOM errors.

How does this combine with the existing message about checking the debug log for details (which comes first)? Would it be possible for this message to only be shown if an OOM error actually occurred?

[vidartf]

These longer texts should probably go into the flag help text as well (instead?).

[telamonian]

I did think about that. The reason why I didn't is that would make the help text for those flags significantly longer/more detailed than the help text for all of the other flags. I guess that's no real reason not to, though. Should I put the longer explanations in the help text regardless?

[vidartf]

"overall performance" -> "initial load times", (unless I'm misunderstanding what the minimizer does)

[telamonian]

You may know more than I do. Obviously minimization helps with initial load (and any subsequent lazy loading). Does it have no other benefit?

[blink1073]

@telamonian, I figured out the config issue. The name field is what determines which config file to load. The LabApp extends NotebookApp, whose name is jupyter-notebook.

The LabBuildApp extends JupyterApp, whose name is jupyter and is meant to be overridden.

I think we goofed by not claiming our name as jupyterlab, so that we could use jupyterlab_config.py for all of our stuff. I think we should use the name jupyterlab for all of the other apps for now, and then move LabApp to jupyterlab for 2.0.

[telamonian]

The LabBuildApp extends JupyterApp, whose name is jupyter and is meant to be overridden.

@blink1073 Wait, what? So does that mean the name of the config file should be just jupyter_config.py?

👍 to making jupyterlab_config.py the config for all Jlab apps in 2.0.

Edit:

I just tested adding the LabBuildApp config to a file named jupyter_config.py, and it does indeed work. Thanks Steve for figuring that out. I'll update the PR in a sec

[telamonian]

Is there a way to generate jupyter_config.py using some variation of

jupyter <something> --generate-config

?

Right now the message just tells people to create a blank file named jupyter_config.py in one of the Jupyter config dirs, which they have to discover using the jupyter --paths command. It's a bit clunky.

[telamonian]

How does this combine with the existing message about checking the debug log for details (which comes first)?

@vidartf I'm pretty sure that this message would print first. Presumably the existing message emits from a scope enclosing the LabBuildApp.start method. Do you happen to know exactly where?

Would it be possible for this message to only be shown if an OOM error actually occurred?

If I knew more about the possible range of exceptions that can be raised in OOM circumstances, then yes. Otherwise, no. From my own experience, I know that sometimes OOM errors manifest as segfaults (which I'm not even sure we can catch reliably in Python). Another question is if we can differentiate OOM errors in a cross-platform way (I don't really know how these things manifest in Windows). Do you know more about it?

[blink1073]

The --generate-config option is added for those scripts who have a python entry point. For us that includes lab and labextension. Currently the name is jupyter labextension, which results in:

$ jupyter labextension --generate-config
Writing default config to: /home/silvester/.jupyter/jupyter labextension_config.py

If we change this to jupyterlab, we get:

$ jupyter labextension --generate-config
Writing default config to: /home/silvester/.jupyter/jupyterlab_config.py

[blink1073]

I say we move to jupyterlab as the name for LabExtensionApp for now and then also for LabApp at 2.0.

[telamonian]

@blink1073 Should we do anything related to this for the jlab 2.0 release?

[blink1073]

Thanks! Let's save the config changes for when we switch to jupyter_server.