The jupyter-fs project is working to create an improved version of the Jupyter filesystem, including support for:
The latest release, which implements all of the above, is available at https://github.com/jpmorganchase/jupyter-fs
In this talk I will introduce the basic concepts of the Jupyter filesystem, the limitations of the current implementation, and explain how jupyter-fs improves the situation. I will also discuss ongoing research into novel filebrowser UIs, which has the goal of making it easier to find and ingest sources of data while writing notebooks.
What actually happens when a user right clicks on a file in JupyterLab's builtin filebrowser and selects "delete"? I will explain how a browser-based, sandboxed app like JuptyerLab is able to make those kinds of modifications to a user's filesystem. I will go over the high level details of the contents API provided by the Jupyter Notebook Server (http://petstore.swagger.io/?url=https://raw.githubusercontent.com/jupyter/notebook/master/notebook/services/api/api.yaml#/), and examine how the JupyterLab frontend and the Notebook Server backend interact in order to carry out these kinds of file transactions.
For most of the simple cases (eg a user is working with their own local files on the same machine where the Notebook Server is running), the existing Jupyter filesystem works very well. However, there are a number of basic use cases which are currently poorly supported or completely unsupported, for example:
Ultimately, the main goal of jupyter-fs as a project is make the Jupyter filesystem flexible and dynamic enough to handle all of the above cases and more, with an emphasis on user experience and making Jupyter in general easier to use. The latest release of jupyter-fs adds support for all of the listed cases above. I will discuss how this was accomplished, and some of the challenges we ran into while making the related extensions.