Should we add a custom `ContentsManager` in `jupyter-lsp` server?

[Michał Krassowski]

Currently we rely on a symlink workaround to allow navigation to files outside of root directory. This is suboptimal for multiple reasons:

• user needs to create symlink (requires enabling Developer Mode on Windows)
• symlink needs to be added to gitignore
• symlink needs to be added to each project
• user may accidentally move files into the symlink when hidden files are shown
• requires enabling hidden files to work in latest server
• there is no server-side way to enforce read-only mode which in past resulted in file corruption because upstream implemented rename based on widget title change (sic!)

Proposed solution

jupyter-lsp should come with a custom ContentsManager for external file access; we could call it GlobalContentsManager or similar

• it should be disabled by default for security reasons
• it should be easy to enable via tratilet (standard jupyter config mechanism)
• it should allow granular access configuration: I am happy to allow access to site-packages and others, but less so to my full disk root; for example:

  GlobalContentsManager.allowed_dirs = [
      '/path/to/site-packages',
      '/path/to/node_modules',
      '/path/to/another/project'
  ]

• ideally it should be easy to switch on from command line without knowing about traitlets, like jupyter password allows to set password without having to worry about where the config is located, we could have:

  jupyter lsp file-access allow /path/to/my/site-packages
  

• it should be read-only be default (for the paths outside of root) but allow user to enable editing via request from front-end
• the request from front-end would only be respected with if explicitally allowed on the server side, by adjusting traitlet:

   GlobalContentsManager.allow_editing: bool | list[str] = false

  again, a command like jupyter lsp file-access allow-editing /path/to/prefix could help users who are not well versed in jupyter config.

Front-end could advise the user to enable access or editing on the server side as needed.

[Nicholas Bollweg]

My concern about a server (AnyNew)ContentsManager: with the extend-by-subclass pattern used by many of the server components, this would immediately make the new contentsmanager incompatible with all the other 3rd-party contents managers. I had hopes for hybridcontents, but it seems to have petered out. We've had some luck on jupyterlite, but it ain't fun.

Another approach would be to make the extension become more aware of the IDrive API, so we could have a second IDrive altogether, powered by a separate endpoint... if it's actually jupyter_server contents code, all the better, but this seems like perhaps the least likely to conflict with other setups. As long as it brought along a bit more info about its root_uri, it should be composable with our existing approaches.

[Michał Krassowski]

Another approach would be to make the extension become more aware of the IDrive API, so we could have a second IDrive altogether, powered by a separate endpoint...

And behind the new endpoint would be our new contents manager which has only one responsibility: serving files outside of root?

It would still require us to do something about third-party contents managers (or them do to something, not sure yet), but would not clash with them, right?

[Nicholas Bollweg]

On Sat, Sep 3, 2022, 08:09 Michał Krassowski ***@***.***> wrote: Another approach would be to make the extension become more aware of the IDrive API, so we could have a second IDrive altogether, powered by a separate endpoint... And behind the new endpoint would be our new contents manager which has only one responsibility: serving files outside of root?

Right. Either with some symbolic names or.

It would still require us to do something about third-party contents managers (or them do to something, not sure yet),

Right... Maybe we'd want some kind of facade that wrapped an existing contents manager _class_, but not the same instance, so that adding another was cheap. Of course, going this way, if we _knew_ a bunch of paths, we could already start LSIF discovery/indexing in the background, which is really how we'd overcome many performance issues.

but would not clash with them, right?

Right, it usually gets prefixed, e.g. like `lsp:lib/python3.10/` (: is otherwise more valid). The jupyterlab-github example is maybe the most complete, as the GDrive one hasn't been touched in so long.

[Michał Krassowski]

Just for completeness debugger also users read-only editors; it sends a debugger source request. The debugger uses custom editor tracker with a custom editor wrapper from custom read-only editor factory.

And there was a read-only editor "code viewer" added in jupyterlab/jupyterlab#12365 (jupyterlab/jupyterlab#12361).

Read only mode was also discussed for the needs of RTC: jupyterlab/jupyterlab#12960