Remove the notebook 5.1 check for large uploads

[jasongrout]

References

Fixes #9601

Code changes

In JLab 3, we are using Jupyter Server, which unfortunately advertises its own version as the notebook version (1.2.1, for example). This trips up this notebook version test.

Since we do not support the notebook server for JupyterLab 3, we can eliminate the version check entirely.

I also normalized the spelling of 'canceled' in the error message to what we are using elsewhere in jlab.

User-facing changes

Large uploads (>15MB) are supported in JLab 3.

Backwards-incompatible changes

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

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

[blink1073]

Thanks!

[blink1073]

Ah, there is one failing test that is relevant: https://github.com/jupyterlab/jupyterlab/pull/9616/checks?check_run_id=1697725231#step:9:145

[jasongrout]

Ah, there is one failing test that is relevant: https://github.com/jupyterlab/jupyterlab/pull/9616/checks?check_run_id=1697725231#step:9:145

All green now except for the ever-failing services test.

[jasongrout]

@blink1073 - if you could re-review after the test changes above, that would be great. Thanks!

[blink1073]

Looks good now, thanks!

[krassowski]

It seems that lab installations using JupyterHub are still running on notebook rather than on jupyter_server, a thing that causes problem to the lsp extension users as when I ported it I assumed I do not need notebook integration anymore (which JupyterLab itself kept). Would this affect the notebook version check and this workaround for legacy installations?

jupyterhub/jupyterhub@f69ef9f

[jasongrout]

I was under the assumption that jlab 3 only ran on Jupyter server, not on notebook. Am I wrong?

[jasongrout]

If I am wrong, then yes indeed this check would need to be added back, if we supported notebook < 5.1

[krassowski]

My very likely wrong impression is that it runs under whatever is available. I came to think that after the users reports from JupyterHub users (running JupyterLab 3.0 for whom our server extension for jupyter_server is not picked up, but the older one for notebook is), seeing the commit mentioned above, and based on that JupyterLab ships with JSON for both notebook and jupyter_server: https://www.github.com/jupyterlab/jupyterlab/tree/master/setup.py

[blink1073]

JupyterHub uses the classic notebook by default, but can be configured to use Jupyter server using an environment variable. JupyterLab can still also run on the classic notebook.

[krassowski]

So the lack of hard breakage seems to be biting the hub users when they try to use an extension with a server component (of note while lab ships both jupyter_notebook_config.d and jupyter_server_config.d, extensions only ship jupyter_server_config.d - see the cookiecutter). This is probably going to bite jupyterlab-git an others too.

Would it be wise to remove jupyter_notebook_config.d and break early to prevent some weird configurations? The current situation will lead to bug reports accumulating on extensions repositories I think and they may not have resources to provide hub support (let alone some exotic deployments).

Or, is it intentional to support notebook and should the cookicutter and extensions and this PR be updated?

[jasongrout]

JupyterLab can still also run on the classic notebook.

Uh-oh. I assumed otherwise. I hope this isn't the only place where I made that assumption.

We'll need to put this 5.1 check in if JupyterLab still runs on notebook 5.0. Do we support notebook 5.0, or do we at least assume notebook>=5.1?

[jasongrout]

Another fix is in #9628 that re-enables the block on notebook < 5.1.