I am trying to follow the build instructions. (The pip install doesn't work as the package isn't on pypi (yet?)).

I clone the repo and cd into the folder jupyterlab-filesystem, i.e. the top-level folder of the cloned repo (the instructions say to cd into jupyterlab_filesystem with underscore which I also tried).

pip instatll -e . works fine but jupyter labextension develop . --overwrite fails.

~/Github/jupyterlab-filesystem$ jupyter labextension develop . --overwrite
WARNING: Build tool `jupyter-packaging` is missing. Install it with pip or conda.
An error occurred.
ModuleNotFoundError: There is no labextension at .. Errors encountered: [TypeError("the 'package' argument is required to perform a relative import for '.'"), 

Implementing rename and copy. The file-system access PR in JupyterLite https://github.com/jupyterlite/jupyterlite/pull/655 will need a proper "rename" method for creating files (mainly because you cannot create a new file given a name with the newUntitled Drive method, so we need to do a rename right after).

Fix #18 and fix #19

Automated Changelog Entry for 0.5.1 on main

After merging this PR run the "Full Release" Workflow on your fork of jupyter_releaser with the following inputs | Input | Value | | ------------- | ------------- | | Target | jupyterlab-contrib/jupyterlab-filesystem-access | | Branch | main | | Version Spec | 0.5.1 | | Since | v0.5.0 |

Implement the newUntitled method.

I am reusing the same pattern as the classic JupyterLab file browser where new folders are name Untitled Folder {N} and new files are named untitled{N}.{ext}

So I managed to get this to work (thanks for your help in the other issue) and I can run a notebook from a local filesystem mounted through this extension and edit files from my local folder in the Jupyterlab IDE. What is not quite clear to me (and what got me excited to try this out straight away): will I be able to access this filesystem from within a notebook, e.g. to access some locally saved data from a notebook executed on a remote server?

Fix reading special characters from the README, should fix the Windows build in https://github.com/conda-forge/staged-recipes/pull/19491#pullrequestreview-1024422500

Looks like this extension was generated without the Binder files.

We should add them to be able to try it easily on Binder.

Alternatively we could also setup docs and deploy a demo site with jupyterlite-sphinx.

Still quite a lot of errors in the dev tools console, but this should help get the basic flow of listing, opening and saving a file at the top-level to work.

The CI on windows fails on https://github.com/conda-forge/staged-recipes/pull/19491#pullrequestreview-1024422500, so let's add a workflow for Windows here

Currently, the only files that can be accessed from a pyodide kernel are those in the "internal memory" of the instance. This can be alleviated by uploading manually files, but it is cumbersome and not practical if the number of files is large.

Describe the solution you'd like

Instead, it would be helpful to have a way of “mounting” a folder in the file system as a folder accessible to jupyterlite through the filesystem API so that the pyodide kernel has a transparent access to local files on the hard drive.

Describe alternatives you've considered

Drag and dropping files works, but it is cumbersome and unpractical for a large number of files and requires all files to be uploaded prior to doing any work. It is also possible to rely on ipywidgets to upload files with the same limitations.

Additional context

• Related to jupyterlite/pyodide only, this is not required for classical jupyterlab instances.

Attempt to fix #17

The implementation I'm suggesting here looks for the mimetype:

    if (file.type === 'image/png') {
      format = 'base64';
    } else {
      format = 'text';
    }

For comparison, jupyter_server seems to try to encode the file content to utf8, if that fails it falls back to base64: https://github.com/jupyter-server/jupyter_server/blob/25ec3ed0dad617a4388db865e9c1a585e54c0b7c/jupyter_server/services/contents/fileio.py#L300-L327

I wonder if we could implement something similar in JavaScript

https://user-images.githubusercontent.com/21197331/162987570-c8084882-9176-4bdb-a3bb-4c969830c60a.mp4

Description

The file browser toolbar is missing a couple of items with JupyterLab 3.4.0.

With JupyterLab 3.3.4

With JupyterLab 3.4.0

Reproduce

• pip install jupyterlab>=3.4.0 jupyterlab-filesystem-access
• Open JupyterLab

Context

This is most likely related to https://github.com/jupyterlab/jupyterlab/pull/12281

• Python package version: 0.4.0

• Extension version: 0.4.0

• Operating System and its version: Ubuntu 20.04 - Chromium 101

This extension works well for opening notebook files from the filesystem :-)

It might be useful to try to catalogue how things are handled differently compared to accessing files from local storage because different workarounds may be required to handle different situations depending on where files are located:

• when opening notebook files from the JupyterLite file system, a copy of the files appears in local browser storage; when opening from the desktop filesystem, no copy appears in local browser storage;
• if you open a data file from the JupyterLite file system and then save it, it appears in local browser storage; it can then be opened programmatically from local browser storage;
• you can't seem to open a data file from the local filesystem and save it into browser storage (I guess if you could do that it could start to provide a way to exfiltrate files?)?
• Irrespective of whether the jupyterlab-filesystem-access extension is installed, you can manually upload a data file from the desktop file system into the JupyterLite file system (this seems to have a side effect of also placing the file immediately into browser storage). I note that the directory path the upload file file picker opens at may be different to the directory path used in selecting the directory on the desktop filesystem. It might be useful if these could be synched?

For now we need to re-open the folders manually after reloading the page.

Maybe the previous folder should be automatically opened is possible (best effort). That could be convenient for those always working with the same folder.

This could also be made opt-in or opt-out via the settings.