Continue signal refactors.

[ericsnekbytes]

Unwind functional args approach and switch to signals for main widget <--> FssTreeItem communication.

[martindurant]

Glad to see you are working on this - I was trying to dig through the TS code a little myself.

I am happy to see the FS creation functions moved from globals in the helper module.

You maybe did exactly this, but: Can we please ensure to pass the kwargs to the frontend in the /jupyter_fsspec/config endpoint, so that the open block looks like

with fsspec.open(path, {kwargs}) as f:
    ...

where the kwargs need to be filled out.

Note that this will need documentation to explain that tokens/credentials should not be stored in the jupyter-fsspec config unless the whole deployment is isolated behind a firewall. Also, the documentation should make clear, that where authentication with storage is automatic (env vars, local config files, etc), such open blocks will only work when the kernel also has access to the same (env vars, config files).

[martindurant]

Should be logging

[ericsnekbytes]

Stray debugging statement, it's been removed 👍

[ericsnekbytes]

The helper was/still is using a manager-singleton approach to obtain fs instances. There are many other potential solutions here, but the underlying principle is that the helper should not be reading the config file or parsing and constructing fs instances itself IMO, that should be delegated to other parts of the codebase that are (already) capable of understanding how a filesystem is defined inside the jupyter_fsspec config file which is a de facto standard invented by the extension).

In this PR, fs construction has been pulled out into two utility functions on the manager because that's probably the easiest way to achieve that goal given the current backend architecture.

Whether the extension is operating in a server-side context using async fs instances, or in a client/kernel side context (synchronous, here), the jupyter_fsspec config is always going to be the source of truth for what a named filesystem is, so the same underlying machinery for fs construction should be used in both contexts IMO to ensure consistent behavior across the extension. There are options for alternative solutions/refactors if we want to pursue them at some point.

You maybe did exactly this, but: Can we please ensure to pass the kwargs to the frontend in the /jupyter_fsspec/config endpoint, so that the open block looks like

I'll chat with Rosio about this and see if she maybe wants to pick up these edits (she's the original author of this functionality), and tagging #107 here so the details are linked :)

[danyeaw]

I gave this a run this morning and it seemed to work well. Do we know why the integration tests are failing, is this something I introduced yesterday?

[RRosio]

I don't think that the changes from the last few days would have caused these failures. It might be an issue with the test itself.. I will try running and debugging locally.