Feature: Add BinderHub support to Launch Notebook

[mmcky]

Summary

Add BinderHub as a launch option in the Notebook Launcher (alongside Google Colab and Private JupyterHub).

Background

The previous QuantEcon theme (quantecon-book-theme) supported BinderHub as a launch target via the launch_buttons.binderhub_url configuration. The new MyST theme currently supports:

• Google Colab
• Private JupyterHub

BinderHub was intentionally deferred from the initial release to reduce scope.

Requirements

• Add a "BinderHub" option to the RadioGroup in LaunchButton.tsx
• Support configurable BinderHub URL (default: https://mybinder.org)
• Build the launch URL in the format: {binderhub_url}/v2/gh/{org}/{repo}/{branch}?urlpath=tree/{repo_subpath}{pagename}.ipynb
• Parse the repository URL from the project manifest (project.github)

Reference

Old theme implementation: https://github.com/QuantEcon/quantecon-book-theme/blob/main/src/quantecon_book_theme/launch.py

Priority

Nice-to-have for initial release. Can be added in a follow-up.

[mmcky]

Decision (2026-06-12): deferred as a demand-driven future request — not closing, not implementing now.

An implementation was built in #86 and deliberately stripped before merge (recoverable from that PR's history, commit 7704c49: radio option + configurable binderhub_url site option, default mybinder.org, book-theme URL shape).

Rationale:

• BinderHub proved flaky in practice (cold starts, capacity) — a launch option that intermittently fails is worse for lecture readers than no option, and creates a support burden.
• Colab is the launch target QuantEcon standardises on, primarily because it provides GPU access for the lectures that need it — something Binder can't match.

If demand for BinderHub appears (e.g. a reliable institutional deployment), the #86 implementation can be revived largely as-is; at that point it should be gated on an explicit binderhub_url being configured rather than always visible.

Related: #87 tracks whether the Private JupyterHub option should also be removed (Colab-first simplification of the launcher).

🤖 Generated with Claude Code

[mmcky]

Research refresh — the requirements above are now stale, and the scope is different than described

Filed as part of a sweep over the launcher's future targets (#153 JupyterHub links, #154 Thebe server connections). The 2026-06-12 decision to defer stands; this updates what deferring now means, because the code it referred to no longer exists.

What changed underneath this issue

The RadioGroup is gone. #87 / #152 removed the Private JupyterHub option and collapsed the launcher to a direct Colab anchor, so the requirement "Add a 'BinderHub' option to the RadioGroup in LaunchButton.tsx" no longer describes anything in the codebase. Adding a second launch target now means deciding what the multi-target UI is, which is the same open question #153 raises and which overlaps #128's toolbar review. Whatever is decided should cover both hub and Binder rather than being settled twice.

This is two capabilities, not one

The original body describes only the first, but they are independent and could land separately:

A launch link to Binder — the book-theme URL shape quoted above, sending the reader to mybinder.org in a new tab. Needs a URL builder plus the multi-target UI decision. The stripped implementation from #86 (commit 7704c49) is still recoverable and covers exactly this.

In-page compute via Binder — Thebe's binder backend. This one needs no URL builder at all: myst-frontmatter's thebe schema already accepts binder: boolean | { url, ref, repo, provider } alongside the lite: true this theme currently defaults to, and it flows through thebeFrontmatterToOptions into thebe-core's binderOptions unchanged. The header Power toggle is backend-agnostic. So a project could plausibly opt into Binder-backed live compute today by setting project.thebe.binder — worth verifying against a real build before writing any code, since it may already work.

The second is arguably the more useful one for QuantEcon: it addresses the Pyodide package gap (numba, JAX) that limits live compute today, which a launch-away link does not.

One trap worth recording

app/components/Page.tsx passes features: { notebookCompute: true, figureCompute: true, launchBinder: false } to ComputeOptionsProvider, which reads like a switch waiting to be flipped. It is not — in @myst-theme/jupyter@1.3.0 only figureCompute is consumed anywhere in the shipped code; launchBinder and notebookCompute are stored in context and never read. Flipping launchBinder: true will do nothing on its own.

Does the deferral rationale still hold?

Mostly. The flakiness that motivated deferring is unchanged, and Colab remains the launch target QuantEcon standardises on for GPU access. But the in-page half above was not considered in 2026-06 (it predates the Thebe work that shipped in v2.3.0), and it is a materially cheaper and more targeted fix for the numba/JAX gap than a launch link. That half may deserve to be re-weighed on its own merits rather than inheriting the launch link's deferral.

Related: #153, #154, #128, #114, and #87 for the design lessons on reader-supplied URLs.