This is cool. Do you still use this? There has been ideas thrown around to add "prompt" cells to marimo that can similarly create outputs or downstream cells and the prompts are serialized to the notebook py file and part of the DAG.
The parent comment wasn't fully correct. marimo doesn't store outputs in the notebook file, but it does have many ways outputs are stored alongside the notebook, or remotely if you'd like:
HTML, ipynb, pickle
It may be preferable to create a variable tied to a UI element that can be used as a toggle to view each analysis.
choice = mo.ui.dropdown(['train', 'split')
data = load(choice.value)
processed = process(data)
visualize(processed)
This way, you can toggle between just more than two if needed. If you need to see both at once, you'd want to refactor the processing and visualizing step into functions, and then just duplicate the finals cell(s).
marimo has a multi-column mode, so you can view them side-by-side
The default "store" is a local FileStore. In your case, it will save the outputs to a file on disk called `my_cache`.
We plan to add more stores like Redis, S3-bucket, or an external server, since you may not always want to commit this file, but like you said want others to avoid the computation.
> One design decision they made is that outputs are not stored
This is not quite true. Outputs are not stored...in the Python file*. marimo does store outputs in the `/__marimo__` folder with settings enabled.
> writing the boiler plate to let the reader load the results.
Therea are some primitives to do this for you, such as mo.persistent_cache. This can be an annotation or 'with' block. It intelligently knows when either the source code or inputs change.
The plan is to take this one step further than storing just the output. Because marimo knows the dependencies of each cell, in a future version, it will store each output AND let you know which are stale based on code changes. This is being built by Dylan (from the blog) and inspired by Nix.
You might be interested in marimo [1], which does not store your outputs in the notebook artifact. Also the files are stored at pure-python instead of json, which LLMs much prefer / easier for them to parse.
Yea, this can be hosted on GitHub pages without any vendor infra (no marimo.app)
These are two separate features:
1) marimo.app + github.com/path/to/nb.ipynb does run on marimo.app infra. this is what the Show HN was about
2) separately, you can use the marimo CLI to export assets to deploy to GitHub page: `marimo export html-wasm notebook.py -o output_dir --mode run` which can then can be uploaded to GH pages. This does not find all the data in your repo, so you would need to stick any data you was to access in a /public folder for your site. More docs here: https://docs.marimo.io/guides/exporting/?h=marimo+export+htm...
it’s already possible to do this: marimo export script nb.py
Pure-python also helps to work with existing tools out of the box: formatting, linting, pytest, importing notebooks as modules, composition, PEP 723 inline metadata
this sort of hackery to work with jupyter notebooks is exactly why we are building marimo (https://github.com/marimo-team/marimo). this should not be the standard
We would like to make this configurable via a setting so you don't need to pass it through the CLI every time. And I agree, maybe a tooltip/notification to nudge them in that direction.
We would also like to auto-detect a pyproject.toml, and use that when desired.
uv + marimo lets you run Python notebooks in a sandboxed environment.
This increases reproducibility and helps prevent environment pollution. If your notebook has inline script metadata, marimo will automatically install the enumerated packages before running the notebook; if it doesn't, marimo will prompt you to install the missing packages on notebook startup.