marimo-notebook-dev

Marimo notebooks are reactive Python notebooks stored as pure .py files. Cells auto-execute when dependencies change, modeled as a directed acyclic graph (DAG).

• marimo uses static analysis to build a dependency graph from variable references and definitions • When a cell runs, all cells referencing its defined variables automatically re-run • Execution order follows the dependency graph, not visual cell order • Each global variable must be defined by exactly one cell • marimo does not track object mutations (like list.append())—mutate in the same cell that creates the object, or create new variables

Each global variable must be defined by exactly one cell. Two strategies to avoid conflicts: • Wrap code in functions (preferred for reusable patterns): `python @app.cell def _(data): def compute_mean_with_new_col(df): temp = df.copy() temp["new_col"] = temp["x"] * 2 return temp.mean() return (compute_mean_with_new_col(data),) ` • Use meaningful, unique variable names: `python @app.cell def _(model1_data): model1_transformed = model1_data.copy() model1_transformed["new_col"] = model1_transformed["x"] * 2 return (model1_transformed,) @app.cell def _(model2_data): model2_transformed = model2_data.copy() model2_transformed["new_col"] = model2_transformed["x"] * 2 return (model2_transformed,) ` Never use underscore prefixes to generate unique variable names. No exceptions.

`python import marimo __generated_with = "0.10.0" app = marimo.App(width="medium") @app.cell def _(): import marimo as mo return (mo,) @app.cell def _(mo): mo.md("# Hello") return if __name__ == "__main__": app.run() ` Key rules: • Each cell is a function decorated with @app.cell • Variables shared by returning tuples: return (var1, var2,) • Cells receive variables as parameters: def _(mo, df): • Execution order follows dependency graph, not position • Name cells descriptively for CellTour targeting: def model_specification():