Exposing Jupyter(Lab) Contents

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.

jtpio / ipylab