Support federated extensions about jupyterlite

[jtpio]

Some ideas for having server extensions as federated extensions:

• a cookiecutter-jupyterlite repo similar to https://github.com/jupyterlab/extension-cookiecutter-ts (maybe a fork?), but for JupyterLiteServerPlugin plugins (example: https://github.com/jtpio/jupyterlite/blob/main/packages/javascript-kernel-extension/src/index.ts)
• distributed as a Python package, with the prebuilt assets going under $PREFIX/share/jupyter/liteextensions
• the jupyterlite cli would also be able to install these extensions from $PREFIX/share/jupyter/liteextensions by moving them to lite/extensions
• extension authors use the same workflow as for normal jupyterlab extensions, with @jupyterlab/builder under the hood. Maybe we can even leverage the --core-path option to not have to add another lite layer on top of it.
• extension authors can then publish their server extension to PyPI, and simply pip install it when they follow a Python drivn deployment

[bollwyvl]

Had a look at this, appears to be a pretty deep well. I got up to where i was loading federated_extensions, but then fell over once they tried to resolve the "known-first-party" stuff. Definitely seems doable, though.

[jtpio]

Thanks!

Had a look at this, appears to be a pretty deep well. I got up to where i was loading federated_extensions, but then fell over once they tried to resolve the "known-first-party" stuff. Definitely seems doable, though.

Do you want to open a draft PR even if it's still a work in progress?

In JupyterLab Classic support for federated extensions is implemented in a very similar way as in the lab examples:

• https://github.com/jtpio/jupyterlab-classic/blob/main/app/index.js and https://github.com/jtpio/jupyterlab-classic/blob/main/app/webpack.config.js
• https://github.com/jupyterlab/jupyterlab/tree/master/examples/federated

Add federated_extensions to pageInfo and the machinery to load them.

Don't we also need a way to create or maintain a list of the installed federated extensions? Since there is no server, not sure we can do something like in jupyterlab_server: https://github.com/jupyterlab/jupyterlab_server/blob/8bcdf52a06bd81e649825e153a3f93947064fe23/jupyterlab_server/config.py#L39

[jtpio]

Also we can limit the scope of this issue to getting the federated extensions (JupyterFrontEndPlugin<any>[]) to work with JupyterLab (and JupyterLab Classic).

Then it would be really nice to be able to add support for "server extensions" too (JupyterLiteServerPlugin<any>[]). Maybe those could go under lite/extensions or something like this. So folks could for example provide additional kernels via a federated extensions, or even swap core services like the contents manager (similar to https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html?#disabling-other-extensions)

[bollwyvl]

PR up, super broken, probably didn't copy-pasta the right stuff.

add support for "server extensions"

yeah, would be very good.

[bollwyvl]

for sure, we need some plan. of course my preference would be that they would Just Work ™️ with existing stuff, deployed to labextensions, with sharedPackages tricks, etc. but i haven't really looked into it, but a jupyter litextension toolpath would certainly be acceptable for people that have decided to throw some weight around, e.g. jupyterlap-lsp, @jupyterlab/pullrequests.

However, we have the opportunity to do something quite interesting to obviate the need for a lot of jumping jacks in the simplest case, e.g. jupyter-videochat, jupyter-server-proxy, etc. that can be faked with static, per-site data, with first-party solutions, e.g. @jupyterlite/openapi, @jupyterlite/asyncapi.

• Given I am a JupyterLite deployer
  - and I lack typescript skills
  - and I really want to use an existing extension
  - but it has a hard serverextension requirement
  - and I can predict what a "valid" response will be
  - and I can use existing OpenAPI/AsyncAPI tooling to describe/validate my description of it
• when I add an OpenAPI/AsyncAPI spec to my jupyter-lite.json
  - and provide some default values
• when a user visits my site
• then it will run without error

I imagine convenience tooling (e.g. YAML ingesting), much like for .whl ingesting, etc. though it should be possible to do it entirely with schema-validateable JSON-banging.

Indeed, these contracts might be an even better API than the existing imperative get, put, etc. and "heavyweight" extension authors may wish to use them. In an ideal world, "real" serverextensions would also have to provide/generate this information.

[bollwyvl]

I think we're pretty good here, I'll open (ha) the OpenAPI thing as a separate issue.