Server detection configuration files are not passed to us from config directories

[krassowski]

Placing LSP server config in jupyter_notebook/server_config.d does not seem to work. See #534 for details; using jupyter_server_config.json still works. The server apps detects the json files:

[ServerApp] Paths used for configuration of jupyter_server_config:
etc/jupyter/jupyter_server_config.d/pyright.json

in several passes. If this is an upstream issue, it needs to be looked into; if this is something at our end, we need to fix/update the docs.

[krassowski]

Any immediate thoughts @bollwyvl?

[bollwyvl]

Yeah, it's weird it doesn't find it... but we should definitely not be distributing a jupyter_(server|notebook)_config.json, as that gets updated by command line stuff (serverextension enable, etc)... nothing that has a cardinality of 1 can be shared by more than one extension, and as we've seen, nobody runs just our stuff.

I'll have a look at validating the setup, but getting it work work with conf.d is critical.

Basic plan:

• make a any_conf_d fixture which gives all the permutations across server and notebook
• validate that the manager loads them

At present, we don't actually instantiate the parent application directly (which is part of why the migration was so straightforward).

We might also need to make the smoke tests more angry.

[bollwyvl]

Oh, yeah, it is an upstream issue... I've had to work around this before on jupyterlab-starters.

I don't think the contract was ever, "you can configure any HasTraits", just "you can configure NotebookApp or ServerApp". It may not even be feasible for the general case.

When conf.d was added to notebook (mainly to remove the need for install-time executed code), there was pushback against actually adding it to the underlying triatlets.config system, as it doesn't actually make a claim about where config files go on disk, so all the Application subclasses have to implement it themselves.

I'll adapt my approach from starters, and while i'm at it, I could add an API route to reload the config, such that folk can put a file in place and have new servers show up... probably won't touch any JS on the PR, though...

[bollwyvl]

#538 is looking good... didn't mess about with dynamic re-configuration, there's probably a lot to consider about that, and actually having the behavior we've had in the docs forever seems more important than that particular async design discussion.