Things that can break with lab by default

[minrk]

Switching to lab by default broke more than I thought. Taking some notes here, to see if there are things we can do to mitigate breakage, or at least point folks to mitigations.

The main information I think we need to surface is ?urlpath=/tree/ or ?urlpath=/notebooks/mynotebook.ipynb allow opt-in to the classic notebook interface, for anyone who wants to preserve that behavior.

Cases that can stop working:

• Dockerfile that doesn't install lab (or not recent enough). This will 404 without any hint as to what went wrong
• environment pins down lab to too-old: I had thought only custom Dockerfiles could 404, but if folks have e.g. jupyterlab==0.34.* in requirements.txt/environment.yml, they can get the 404, too
• filepath and/or default URL where they just don't want to change (I view this one as purely a documentation issue, just like it was for lab users before it was the default, since nothing is actually broken)
• filepath or default ui, with extensions that don't work in lab (I don't think we can detect this, so it seems the same as previous in practice, despite users facing actual breakage)

I think the 404s are the harshest ones, and things we should consider trying to fix.

Mitigations:

• filepath breakage could have been avoided if we updated the form to use a new argument to unambiguously choose lab, and leave plain filepath as classic notebook. I'm ambivalent about this, because part of the point of filepath as it was, was to allow it to follow UI updates as they came, but user expectations are more important than developer intentions
• is there a way we could detect availability of jupyterlab before picking default url? This is not hard with a custom entrypoint, but we have very little available to us with custom Dockerfiles. Maybe if we mount an executable from a volume, we could do something without modifying the image?
• time-based choices - I've long thought about using last modified time to try to avoid breaking changes, and only use new options for builds since the date they were introduced (e.g. pypi time machine, etc.). I'm not sure that this is a good idea, but it intrigues me. But we currently don't have access to this information.
• we could 'advertise' a link back to classic ui via a lab extension, if folks think that would be more helpful than noisy. I'm not sure how to do it in a way that's sufficiently visible for those who need it and not annoying for everyone else

[minrk]

I think this will work to avoid breakage in most of the cases we've seen so far:

if we change the default launch command to:

["python3", "-c", 
"""
import sys
from distutils.version import LooseVersion as V
try:
  import jupyterlab
  major = int(jupyterlab.__version__.split(".", 1)[0])
except Exception:
  have_lab = False
else:
  have_lab = major >= 3

if have_lab:
  # if recent-enough lab is available, make it the default UI
  sys.argv.insert(1, "--NotebookApp.default_url=/lab/")

# launch the notebook server
os.execv("jupyter-notebook", sys.argv[1:])
""",
]

This moves the default_url selection down one level, out of the chart config (c.Spawner.default_url) into the command (c.Spawner.cmd).

Need to think carefully about where this should go, whether it's in the mixin source or if putting it directly in the singleuser.cmd field in the chart will work, which would be simplest.

[hackfin]

is there a way we could detect availability of jupyterlab before picking default url? This is not hard with a custom entrypoint, but we have very little available to us with custom Dockerfiles. Maybe if we mount an executable from a volume, we could do something without modifying the image?

Mounting a custom launcher like the above looks like the most reasonable 'legacy support' solution to me (I'm one of those evil Dockerfile users).

It appears to be tricky to find other web based fallback solutions (redirects...) to fix a 404 when inside a custom Docker environment. There could maybe be a server extension package just for this purpose, but would require to build new containers.

[minrk]

Yeah, since Binder doesn't add anything to the containers, anything that involves installation doesn't solve the problem (there is also already a package that provides this solution - jupyterlab).