Exposing Jupyter(Lab) Contents

[bollwyvl]

Elevator Pitch

Offer access to Jupyter Contents, as viewed by a JupyterFrontend, as a set of widget subclasses.

Some points worth considering for wrapping

• ContentsManager
• IDrive
• ContentsModel
• FileBrowser
• DocumentManager

Motivation

The long-standing issue of "what is a file" according to Jupyter Kernels, a Server, and Clients creates a number of difficult-to-resolve situations. While a widget-based solution may not be the optimal, general-purpose, long-term solution, it's easier to imagine and demonstrate on this repo than probably anyplace else.

Design Ideas

A low-level sketch:

app = JupyterFrontEnd()
contents: ContentsManager = app.service_manager.contents
root: ContentsModel = contents.get("/")

for child in root.contents:
    print(child.contents)

untitled = ContentsModel(type="text", content="# hello world", path="untitled.md")

contents.save(untitled)

Making all of the above feel widget-like (almost all of the above are several layers deep of async) and still be efficient would of course be a challenge. But there are probably worse things than introducing some async methods which then get cached as trait members.

Sadly, a lot of the methods are rather private, such as enumerating _additionalDrives and even finding _defaultDrive.

The IDrive interface, used in things like GitHub and IRODS, could make this very interesting indeed, as well as a wrapping such a drive in a FileBrowser which could be attached to a Panel.

This would give someone the tools to rapidly prototype browsing just about anything by answering, at the very simplest, only the get method.

Going straight to the sharedModel and all its... ahem.. features... might be a bridge too far.

[bollwyvl]

#133 shows how a quick-and-dirty approach to using the low-level ContentsManager.get and .save can actually do some work against files.

As this is not evented, it's not very much fun, but does show some of these things are possible... and some things will need to be at this level, such as drive registration.

As part of this would be relevant to how custom, existing IDrives feel, we'd probably want to update the lite stack and add an extension with an IDrive implementation such as jupyterlab-github.