“The Mixtape in CausalPy” example translation repo

[drbenvincent]

Goal: create a separate repo that re-implements the analyses (code + results/figures) from Scott Cunningham’s Causal Inference: The Mixtape using CausalPy, without duplicating book text.

Does The Mixtape have a companion repo / data?

• The online book is at: https://mixtape.scunning.com
• There is a companion GitHub repo with data + program files: https://github.com/scunning1975/mixtape

Plausibility assessment

This is highly plausible and likely to be valuable.

• Strong method overlap: Mixtape’s core applied chapters (RD, IV, DiD, Synthetic Control) align directly with CausalPy’s current experiment APIs.
• Good “translation repo” precedent: It’s common to publish “same examples, different language / PPL” repos as a practical on-ramp (Python vs R; PyMC vs Stan; etc.).
• Primary complexity is engineering, not feasibility:
  • dataset plumbing (download/standardize)
  • getting plots “close enough” (not pixel-identical)
  • documenting “why results differ” (priors, Bayesian vs OLS defaults, random seeds)

Related CausalPy tracker: feature gaps vs Mixtape are documented in issue #622.

Scope boundary (important)

To stay aligned with your stated intent:

• Do: recreate analyses, estimands, and key figures using public data and your own code.
• Do not: copy/paste book text, reproduce full narrative structure, or redistribute copyrighted content.
• Do: link to the book for context and cite it; keep notebooks terse and focused on “how to run this in CausalPy”.

Recommended repo structure

• Top-level mapping table: a simple chapter→notebook matrix with status.
  • Example columns: chapter, example, method, dataset, causalpy_method, status, notes.
• One notebook per applied chapter (or per major example):
  • notebooks/05_matching.ipynb
  • notebooks/06_rd.ipynb
  • notebooks/07_iv.ipynb
  • notebooks/08_panel.ipynb
  • notebooks/09_did.ipynb
  • notebooks/10_synth.ipynb
• A tiny data layer:
  • Prefer pulling data from causaldata when available.
  • Otherwise, vendor only what licensing permits (or download from the Mixtape repo in CI).
  • Keep a data/README.md documenting provenance and how it’s fetched.

Which parts will be easiest vs hardest?

• Easiest (CausalPy-native):
  • RD, IV, DiD (baseline), Synthetic Control
• Likely requires additional work / interim baselines:
  • Matching/subclassification: may need a small “baseline” implementation (e.g., sklearn + your own matching utilities) until CausalPy supports it directly.
  • Panel-data “workhorse” FE regressions: may need statsmodels/linearmodels baselines for parity, with CausalPy used where it’s the best fit (e.g., DiD/event-study once PRs land).

Jupyter vs Marimo vs Quarto for this repo?

Given your goal (“persistent results users can browse on GitHub”), I agree with your lean: Jupyter notebooks are the better default.

Quarto (often the best publishing layer)

Quarto can be an even better fit if you want a browseable website (e.g., GitHub Pages) with stable URLs, navigation, and fully rendered outputs.

• Pros
  • Publish a clean, book-like site (chapters, sidebars, search) with rendered outputs.
  • Works well with Jupyter notebooks as inputs (and also Markdown).
  • Encourages reproducibility via explicit render steps (great for CI).
  • GitHub Pages deployment is a common, well-supported workflow.
• Cons
  • Adds a build/publish layer to maintain (Quarto config + CI).
  • You’ll need to decide whether to commit rendered artifacts (usually “no”, except the built site branch).

Jupyter notebooks (recommended default)

• Pros
  • Render natively on GitHub (users can browse outputs without running anything).
  • Familiar format for “example translation repos”.
  • Easy to pair with CI execution (e.g., papermill/nbclient) to ensure notebooks stay runnable.
• Cons
  • Outputs can create noisy diffs unless you adopt a policy (e.g., save selected outputs only, or strip on commit and publish rendered docs).

Marimo notebooks

• Pros
  • More app-like interactivity; reactive execution can be great for teaching.
  • Can reduce “stale state” problems common in classic notebooks.
• Cons
  • GitHub rendering/browsing experience is not as universal as .ipynb.
  • Community expectation for “book translation repos” is still overwhelmingly Jupyter.

Practical compromise

• Keep Jupyter as the canonical, review-friendly source artifact.
• Use Quarto to render those notebooks into a GitHub Pages site for the best browsing experience.
• Optionally add Marimo versions later for a subset of notebooks (e.g., interactive RD bandwidth sensitivity explorer), if that becomes compelling.

What “done” looks like (success criteria)

• Each applied chapter has at least one notebook that:
  • loads the chapter dataset
  • runs a comparable identification strategy in CausalPy (or a documented baseline when missing)
  • reproduces the key result figure(s) in spirit
  • clearly states any differences vs the book’s implementation choices