Exposing session information to kernel
#44
Conversation
|
Thanks @TK-21st for this! |
|
It should be possible to fix the failing Python lint job by running black locally with: Although the pre-commit hook should run it by default on commit. |
src/plugin.ts
Outdated
| @@ -36,6 +38,9 @@ const extension: JupyterFrontEndPlugin<void> = { | |||
| widgetExports.ShellModel.shell = shell; | |||
| widgetExports.CommandRegistryModel.commands = app.commands; | |||
| widgetExports.CommandPaletteModel.palette = palette; | |||
| widgetExports.SessionManagerModel.sessions = app.serviceManager.sessions; | |||
| const focusTracker: FocusTracker<any> = (app.shell as any)._tracker; | |||
There was a problem hiding this comment.
Wondering whether this should be the lab shell focus tracker, or the INotebookTracker and IConsoleTracker?
There was a problem hiding this comment.
Makes sense to clean that up I feel.
But I was also considering the super edge-case where the user wants to use, say, CodeCell in a custom extension not tracked by INotebookTracker or IConsoleTracker, and hope to inject some code there with ipylab, then this won't work.
But then again, a SUPER edge case.
There was a problem hiding this comment.
Right, but it could indeed be useful! Maybe we could track that in a separate issue?
But I was also considering the super edge-case where the user wants to use, say, CodeCell in a custom extension not tracked by INotebookTracker or IConsoleTracker, and hope to inject some code there with ipylab, then this won't work.
The custom extension could provide its own track (ICustomTracker), and then ipylab could require this token as optional in the activate function. Although that would mean making a change to ipylab everytime we need to support a new extension. So yes a more general focus tracker could probably scale better.
There was a problem hiding this comment.
Right, but it could indeed be useful! Maybe we could track that in a separate issue?
Sure!
So yes a more general focus tracker could probably scale better.
Agreed! So would you say we go with INotebookTracker and IConsoleTracker for now or keep using the generic FocusTracker as it is now?
There was a problem hiding this comment.
Agreed! So would you say we go with INotebookTracker and IConsoleTracker for now or keep using the generic FocusTracker as it is now?
I'll give it a try locally to see what it looks like with the FocusTracker.
At first it felt more natural to go with INotebookTracker and IConsoleTracker as those are the "public" tracker exposed from the notebook and console extensions. Also we can add them as optional in the activate function. Which means they are available only if the environment provides them (would be interesting to try in a custom lab build some day! #33)
But if the focus tracker might just keep things simpler actually! (checking for widget.sessionContext.session? directly).
There was a problem hiding this comment.
Also ILabShell has a currentWidget and currentChanged (and is already exposed as Shell in ipylab).
Maybe this could be a substitute to the focus tracker?
There was a problem hiding this comment.
Also
ILabShellhas acurrentWidgetandcurrentChanged(and is already exposed asShellin ipylab).Maybe this could be a substitute to the focus tracker?
Ooo, I did not know that.. that'd certainly be better than exposing a private attribute..
Let me change that
There was a problem hiding this comment.
Changed to using shell.
|
Turns out it needed to format
😮 |
|
Sorry was trying to play with some code in a separate repo and accidentally pushed to the wrong remote. |
|
reverted the dumb mistake in #45. |
Exposing `session` information to kernel (fix a commit error in #44)
addresses #43
sessionManagerinstance to user (app.serviceManager.sessions)