Skip to content

Marimo Project-Root Working Directory

Marimo notebooks in this repo now normalize their working directory to the project root during app.setup.

Why

VS Code marimo sessions may start a notebook with the notebook's own folder as the process working directory. That makes relative export paths like exports/matrix/chicken resolve under notebooks/.../exports/... instead of the repo-level exports/ tree.

This mirrors the problem described in marimo-lsp issue #343, where users want notebook-relative launches to still behave like workspace-root launches for data and artifact paths.

Implementation

  • Shared helper: notebooks/project_root.py
  • Each marimo notebook imports set_cwd_to_project_root() inside with app.setup:
  • The helper prefers the executing notebook's location via mo.notebook_location()
  • It then walks upward looking for a project marker, currently pyproject.toml or .git
  • Fallback search starts include the helper's own directory and the current working directory

Effect

  • Relative paths like exports/..., logs/..., and data/... now resolve from the repo root in marimo notebooks
  • This keeps marimo behavior closer to historical Jupyter setups that used a workspace-root notebook file root

Tradeoffs

  • This intentionally changes process-wide cwd for notebook execution
  • Code that expected notebook-local relative paths will now resolve relative to the repository root instead
  • Non-marimo helper modules such as notebooks/utils/dynamics.py still just consume whatever paths callers pass in; the cwd normalization happens at notebook entrypoints

Alternatives

  • Convert all notebook output paths to explicit absolute paths derived from a shared project_root() helper without changing cwd
  • Add VS Code task wrappers that launch marimo with ${workspaceFolder} as the shell working directory
  • Wait for a future marimo / marimo-lsp setting that supports workspace-root cwd directly