When an error occurs, a traceback is shown. It often includes a path to the files where the error occurred. Users would benefit from a way to open that file. The file can be either:
- within the Jupyter root directory (this can be handled by
jupyter-server
’sContentsManager
if running with a server), or - in a remote location (when remote kernels are used)
While ContentsManager
can also handle some remote files (if subclassed), it may not be aware of the library/package scripts specific to runtime environment if this is separate from storage which is available to the contents manager.
I wonder whether kernels should be able to expose (potentially read-only) some of their environment source files if needed (if those are remote and separate from the contents manager scope). We already do that for the purpose of the Debugger Adapter Protocol (via debug-request), but it is not currently exposed by kernels which are not debugger-enabled and requires the debugger to be on (which has an overhead). While we could “just” add a new message, it is not clear if we want to go this way (and will require a JEP consensus), especially because only a subset of kernels will ever require this (i.e. most kernels today are local, not remote).
Where there any discussions about for example proxying a subset of ContentsManager
API by remote Kernel Provisioners? My question comes because I understand that provisioners will enable remote kernels in a clean way and replace the current implementation in Enterprise Gateway in the future, is this correct?