Add option to open a notebook in NbClassic if it is enabled; show "Open in..." dropdown menu if there are multiple options, show single button otherwise

[andrii-i]

• Dynamically detect if NbClassic is enabled
• If NbClassic is installed, add option to open a notebook in NbClassic to "Open in..." menu, command palette, "View" menu
• Show "Open in..." dropdown menu if there are multiple options, show single button otherwise
• Fix some lint errors in test files

Fixes #6746
Fixes #6792

"Open in..." dropdown menu

Single button

Command palette

"View" menu

[github-actions]

👈 Launch a Binder on branch andrii-i/notebook/detect_nbclassic_dynamically

[jtpio]

Thanks @andrii-i for working on this.

• changes introduced in

Since this feature is specific to the notebook / nbclassic use case, maybe we could add the logic in the notebook repo directly instead of jupyter-server/jupyter_server#1272?

Probably the page config option could be set somewhere here:

notebook/notebook/app.py

Line 35 in 573becf

def get_page_config(self):

[andrii-i]

@jtpio thank you for looking into this PR. I was under assumption that because nbclassic is a server extension I need to expose this information in https://github.com/jupyter-server/jupyter_server through API endpoint or PageFile. Is it possible to detect if nbclassic is installed from lab-extension alone? How? I'd be happy to try.

[JasonWeill]

The PyPI docs capitalize the project as NbClassic (first C capitalized): https://pypi.org/project/nbclassic/

[andrii-i]

Thank you @JasonWeill. Updated capitalization in user-facing commandLabel and commandDescription to NbClassic, also updated screenshots in the PR description.

[JasonWeill]

Consistent interCaps

[jtpio]

thank you for looking into this PR. I was under assumption that because nbclassic is a server extension I need to expose this information in https://github.com/jupyter-server/jupyter_server through API endpoint or PageFile. Is it possible to detect if nbclassic is installed from lab-extension alone? How? I'd be happy to try.

I would assume it should be possible to detect it here from app.serverapp similar to what is done here?

https://github.com/jupyter/notebook/blob/573becfa6470ce2b9b1a1451c5a54955d57b9c7a/notebook/app.py#LL52C28-L52C41

Also it would be fine to have that logic here in the notebook Python code, since it's just about passing an additional page config option. Which means it's not specific to the lab extension only, but in this case it should be fine.

[andrii-i]

@jtpio I tried to access app.serverapp.extension_manager.extensions in notebook/app.py and it works, thanks for the suggestion

[jtpio]

@andrii-i since the default is now a button we'll have to update the reference snapshots for the UI tests.

Thinking we could also expand the UI tests to cover the case when nbclassic is installed or not (but could be done in a separate PR)

[andrii-i]

Failing test seems to be flakey. It passed in previous run, I can't reproduce it locally or on Gitpod

[andrii-i]

Also after notebook is opened in JupyterLab shell when nbclassic is installed, there is still only one button

[jtpio]

Also after notebook is opened in JupyterLab shell when nbclassic is installed, there is still only one button

Ah right, this is likely because the page config will only be passed to the frontend when served from the notebook application. Wondering if a better could then to pass a parameter via a server extension that would be distributed via the lab extension.

[andrii-i]

@tonyfast tagging you to follow up on a discussion during todays JupyterLab call about displaying dropdown menu in cases where there is more than 1 option in "Open in..." menu (used to be called "Interface" menu) and a button otherwise. Please see these threads for a previous discussion on the topic: #6746 (comment), #6866 (comment). Bottomline: we don't expect users to see this UI in its different variants often (and never at once) so having extra friction of dropdown menu with only 1 option seems to be not worth it. Would be interested to hear your opinion.

[tonyfast]

originally, i thought it didn't make sense to switch the semantics of the UI. now that i see it is a feature being degraded and deprecated then switching semantics makes sense to me. they actually are different things now. steady on. good stuff. thanks for including me.

[andrii-i]

@tonyfast Thank you for giving this a look and providing feedback

[jtpio]

Thanks!

[andrii-i]

Thank you @jtpio