Refine task of improving JupyterHub/Binder launch feature

[agoose77]

The scene of execution and launching of interactive content in MyST is complex (because the scene is complex!).

At the heart of this, I think there are three possible ways a user might want to provide launch and/or execution support for their content:

1. Build image from content & environment repo (repo2docker) using a BinderHub
   • MyBinder.org
   • Generic BinderHub
2. Build image from environment repo (repo2docker) using a BinderHub, and provision content from separate repo with nbgitpuller
3. Use pre-existing image and provision with nbgitpuller on a JupyterHub
4. Talk to pre-existing server without provisioning environment or content (manual)¹

The above strategies should work for both Jupyter and JupyterLite distributions, both for execution (Thebe) and launch links.

I think our config probably needs a re-work to reflect this, and Thebe might need some more support to facilitate it.

Here's a sketch of how our config might change:

Existing configuration (simplified)

project:
  jupyter: undefined(false) | boolean | object | 'lite' | 'binder'
    lite: boolean
    binder: undefined(false) | boolean | object
      url: string (url)
      provider: string (git | gitlab | github | or custom)
      repo: string (org-name/repo-name | url | string)
      ref: string (undefined | string)
    server:  undefined | object
      url: string (url)
      token: string (any)

Suggested configuration (simplified)

project:
  jupyter:
    lite:
      # JupyterLite can build custom environment
      environment:
        url: string (url)
        provider: string (git | gitlab | github | or custom)
        repo: string (org-name/repo-name | url | string)
        ref: string (undefined | string)

      # Does it make sense to pull content at runtime? 
      # Binder does this because images are ephemeral
      # We have to build the env at build-time anyway
      # content:
      
    binder:
      # Binder can build images
      environment:
        url: string (url)
        provider: string (git | gitlab | github | or custom)
        repo: string (org-name/repo-name | url | string)
        ref: string (undefined | string)

      # nbgitpuller can provision image
      content:
        url: string (url)
        provider: string (git | gitlab | github | or custom)
        repo: string (org-name/repo-name | url | string)
        ref: string (undefined | string)
    hub:
      # Hubs can't build images
      # environment:

      # But can configure spawn
      options:
        ...

      # nbgitpuller can provision image
      content:
        url: string (url)
        provider: string (git | gitlab | github | or custom)
        repo: string (org-name/repo-name | url | string)
        ref: string (undefined | string)
    server: ...

Footnotes

1. This only makes sense for Thebe, probably. But perhaps not. ↩

[agoose77]

1. Rename content to provisioning :)
2. Nest nbgitpuller as a provisioner type.

[agoose77]

This needs more work, but I don't have cycles in this very moment to undertake it.

More notes:

Hubs can actually support image building. There are actually the following deployment types:

• binder
• jupyterhub with static profile list
• ephemeral jupyterhub (pre-configured image(s), no per-user auth, no storage)
• jupyterhub with binderhub (c.f. jupyterhub-fancy-profiles)

Therefore, we might want to interrogate the deployment target to determine whether the defined launch information is valid.

Some targets can accept an image name, others an image definition. Some accept spawn args, others not?

Lite can use litegitpuller, so we should support that.
For now, we can only use a single provisioner. (nbgitpuller is limited)