Open echarles opened 10 months ago
... or only specific aspects of the serviceManager could be provided (content, kernel(specs)...), see the current definition of a serviceManager. This would allow to create a more composable Jupyter Context with contents provided from A and kernels provided by by B.
interface IManagers {
/**
* The builder for the manager.
*
* @deprecated will be removed in JupyterLab v5
*/
readonly builder: Builder.IManager;
/**
* The contents manager for the manager.
*/
readonly contents: Contents.IManager;
/**
* The events service manager.
*/
readonly events: Event.IManager;
/**
* A promise that fulfills when the manager is initially ready.
*/
readonly ready: Promise<void>;
/**
* The server settings of the manager.
*/
readonly serverSettings: ServerConnection.ISettings;
/**
* The session manager for the manager.
*/
readonly sessions: Session.IManager;
/**
* The kernel manager of the manager.
*/
readonly kernels: Kernel.IManager;
/**
* The kernelspec manager for the manager.
*/
readonly kernelspecs: KernelSpec.IManager;
/**
* The setting manager for the manager.
*/
readonly settings: Setting.IManager;
/**
* The terminals manager for the manager.
*/
readonly terminals: Terminal.IManager;
/**
* The user manager for the manager.
*/
readonly user: User.IManager;
/**
* The workspace manager for the manager.
*/
readonly workspaces: Workspace.IManager;
/**
* The nbconvert manager for the manager.
*/
readonly nbconvert: NbConvert.IManager;
}
****
As discussed with @fcollonval the JupyterContext could receive an serviceManager created from the outside instead of creating its own.