-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check List CLI #2
Comments
All "old" extensions are going to fail this test until they switch from NBClassic enables the ServerApp to find these extensions, even when their config exists in the old location (jupyter_notebook_config.d), but the |
Hmm, I think |
I think the only way to do this is to add a shim directly in jupyter_server. Ideally, we might hijack this in nbclassic, but I think this would be tricky and (possibly) buggy. |
I'll look at this more this afternoon. |
Hmm, what happens if a package has metadata for both? Do we load it as a new style extension? If so, then that would be a way for folks to bridge the gap. |
That's actually an important question that I haven't verified... The answer should be yes. In that case, if the package has metadata for both, both will get installed and |
jupyter/nbclassic#22 ensures |
This doesn't solve the issue here of course. I think this means we need to: 1) submit PRs to all server extensions with the new extension config, 2) add a message to jupyter_server's list command saying this won't list items in jupyter_notebook_config, or 3) add logic in jupyter_server to list these items temporarily... |
I think server should be able to list them but not have logic to load them, at least during a transitional period. |
I think it should also warn if it finds them but |
Example:
The text was updated successfully, but these errors were encountered: