Provide a way for kernels and server extensions to expose static assets about jupyterlite

[bollwyvl]

So actually, I've been thinking the most natural API for user-serviceable files is:

• drop files in files/
• some top-level JSON encodes a (nearly) equivalent Contents API response tree
  • this could (but doesn't need to) end up in /ap/contents (maybe as some well-known file, __jupyterlite_contents.json) which can pre-seed the contents manager
• the contents manager is adjusted to be copy-to-localStorage-on-write
  • load time is already going to be brutal, adding the actual contents will exacerbate the matter

[jtpio]

This would also be useful when providing kernel resources such as logos, which are for now manually placed in https://github.com/jtpio/jupyterlite/tree/main/app/kernelspecs

[bollwyvl]

Been thinking about this more while fiddling with #48: the approach in jyve was to get the stuff into package.json and having a custom key, and I feel this approach is worth considering.

The package.json will always be part of an npm package, and is still consumable by other languages (a la #41). A critical thing to add would be a schema to keep multiple implementations honest... it seems like mirroring the api routes as closely as possible probably makes the most sense... but some special notation will be required as we're talking about:

• in-line JSON fragments
• individual files
• lists of files

For things like pyodide wasm, it's a little murkier: in a traditional server-backed setup, these would just be !url-loader or !file-loaderd in, and then served from the share/labextensions path.

Similarly, being able to specify files (a la #30) would also have enough information to drive contents without storing the base64-encoded JSON...

so, perhaps:

"jupyterlite": {
  "routes": {
    "/api/kernelspecs#/kernelspecs/pyodide": {
      # the actual kernelspec
    },
    "/api/kernelspecs/pyodide/logo-32x32.png":  "style/logo-32x32.png", # an implicit path
    "/static/labextensions/@jupyterlite/pyodide-kernel/": [{ # a "mount point"
        "path": "pyodide-dist",
        "files": ["pandas.data", "pandas.wasm"] # etc. globs are... hard
    }],
    "/files/examples/": [{
      "path": "docs",
      "files": ["pyodide.ipynb"]
    }]
  }
}

in webpack land, these could be interepreted, potentially with that asset plugin, but there's also enough data here to do good things without it.

as a publisher, one could then disable particular routes if they didn't want them by configuring their .jupyterlite file (which actually could be a valid package.json, i guess, as it has pretty good metadata already... just no scripts please!)

[jtpio]

Other things to consider:

• renaming files which are then persisted in local storage: should the content under files be downloaded again on the next page reload
• distinction between writable and read-only data

[bollwyvl]

@jtpio do we basically have this now, or is there more to do? I feel like the only things that are special anymore are kernel icons... and p5 takes care of itself somehow without that, so maybe we just need a new issue/rename this issue just for that task.

[jtpio]

I think so yes.

For example p5 ships its own logo here: https://github.com/jupyterlite/p5-kernel/blob/212453c5d0ea35552f142fe2f779d4568a303192/packages/p5-kernel-extension/src/index.ts#L15
Xeus-based kernels also bring their own files (workers, glue js code).

So let's close this issue. Thanks for bringing that up!