Integrate into existing Jupyter-based workflows

Awesome stuff here! Maybe these have been brought up elsewhere, if so, feel free to close!

elevator pitch

Having an installable, python-based package with hooks for various other jupyter tools with a couple features would make it easy to adopt for workflows folk are already invested in.

Use Cases

• as a Jupyter user, locally be able to interactively build up a custom jupyterlite site with contents, custom extensions, etc. and do whatever you need to with the files
• as an extension developer community, build a demo site in CI and deploy to somewhere (e.g. github pages)

Features

nbconvert

One of the jyve features I loved building is the nbconvert exporter. That code’s pretty rough, but it does the thing of marshalling all the static assets into a folder, ready to be committed to gh-pages (or dragged into SharePoint 😱) for demos.

I’m imagining two, not necessarily mutually exclusive outputs of:

• a full editable lab
• a single Document that looks like nbconvert, etc. but is built out of lab renderers
• a couple Documents, one per page

With those pieces, one could integrate nicely into other workflows like sphinx, jupyter-book, mkdocs, nbviewer, binder, etc.

design ideas

• a python package
  • an entry_point for jupyterlite site
  • this would make it show up in various CLI and API endpoints
  • all/some of the jupyterlite static assets as either…
    • data_files for “simplicity”
    • package_data it’s gonna be big, duplication in wheels is no fun

As nbconvert likes to make one file, the default output would probably most usefully be a .zip file… not so much fun for previewing, but quite handy for moving around (as again, it’s gonna be big). But if it gets more complicated…

labextension

There are bells and whistles that would need more tweaking than what the exposed nbconvert API offers. It would be lovely to have an in-juptyerlab(-classic) extension that built jupyterlite sites and then did… stuff with them.

design ideas

This part would have to be in data_files, but wouldn’t be very big.

• offer it as a new File > export as… > custom jupyterlite
  • open a new mainareawidget (or whatever makes sense in classic)
    • capture the advanced options as a JSON schema
      • make a JSON schema from ui
    • a drop area for adding additional contents paths

As to targets, I’m imagining other outputs/targets, such as:

• git bundle
• start hosting the site
  • just /files
  • serve on a federated content network, e.g. dat/ipfs
    • these would work quite well if the core assets (and labextensions folk might include) end up being very static, as they would get deduplicated in the network and locally

[bollwyvl]

And thanks for sharing ideas and the suggestions

well, you know the saying about opinions… but i’m sure we can agree PRs are better, even for talking about stuff… I’m just having to circle the beast before going for the kill. This issue already sounds like a couple PRs!

folks coming from a more traditional web dev background

Yes, that is an important group: those that don’t know jupyter but do know web junk should be able to use this in their workflows once #7 hits. Indeed, the distinction between “app” and “packages” is probably an illusion, as it probably all has to go up.

Those of us that do know jupyter are the sods stuck building all this filagreed junk on top of the specs and protocols, and #7 will help us, too.

But the audience this issue is pointed at is the existing members of the jupyter community that have been crying out for an easy-to-share mechanism of their existing interactive computing experience that doesn’t involve npm, CI, kubernetes, etc. for years. True static, kernel-based publishing would actually mean you could deploy an interactive journal paper, etc. without the “productionizing” step.

If, as an analyst working in python on windows, an in-UI way to get a viable static bundle of my work and the lab extensions i want but without downloading 435mb of node_modules, that i can drag-and-drop into SharePoint… that’s a big step forward.

[bollwyvl]

(sort of) have nbconvert working: https://github.com/jupyterlite/jupyterlite/pull/756#issuecomment-1214554290