Serialize outputs in separate file so app can be viewable when auto-instantiate is off

[mscolnick]

Description

Serialize outputs in separate file so app can be viewable when autorun is off. This is different from persistent caching, even if configured on all cells. This is much cheaper and just stores the HTML of the outputs (which can be easily found in the SessionView), this does not "hydrate" the runtime, so all outputs will be considered stale.

This helps with users who always use auto-instantiate=off

Suggested solution

SessionView has a serialize/deserialize function on it that can read/write to an outputs file. This will be stored in the shared __marimo__ folder, similar to persistent cache and auto-export.

Proposed path would be __marimo__/outputs.json.
Other options could be __marimo__/session.json, if somehow it ends up containing more than outputs (variables, datasets schemas, etc)

Alternative

No response

Additional context

No response

[leventov]

FWIW, outputs (stdout, stderr) should also be stored along with the "main" persist output (i.e., locals) for persisted blocks or cells. This is so that faithful outputs are restored when a block or cell execution is skipped.

On the other hand, if a logger is used the cell code (or inside any of the logic that is called by the cell) and it is configured to output time, the output may become more rather than less confusing.

[mscolnick]

Agreed, we will include all: stdout/stderr and display outputs

[mcburton]

Just a quick, half-baked thought about the serialization format. Could the HTML export be used? It would be nice if the separate file was an existing standard and viewable/meaningful in its own right. Might not make sense but I was just musing about re-using html exports and also thinking about the implications for sharing Marimo notebooks with the serialized outputs.

One thing I like about Jupyter notebooks is the ability to share (stale) outputs in the notebook. I know it creates a lot of problems but it’s useful when reviewing static notebooks. For example, my students submit assignments as ipynb and I want to quickly review their code & output, not re-execute their code to generate outputs.

With Marimo, the challenge is where to put outputs to keep the notebook pure python. To me, HTML is the most logical way to serialize outputs for sharing. Maybe what I’m actually asking for is allowing Marimo to open HTML export and reconstitute a live python notebook with stale outputs…if such a thing is possible.

Edit: maybe exporting Marimo to ipynb addresses this…or maybe ipynb is the serialization format 🤪

[leventov]

@mcburton I think what you want is Quarto export: https://github.com/dmadisetti/quarto-marimo

I'm not sure this is related to this issue, though. Or, do you want to ensure that code cell outputs are interpreted as Markdown as well as mo.md() calls? Then I guess you can wrap the relevant part into a mo.md() yourself, such as mo.md(openai.chat_response(prompt="Make a table comparison between option A and B...")) (assuming that OpenAI will by default output tables and all other text markups as markdown).

[mscolnick]

@mcburton we do store outputs in the HTML. it could be an interesting idea to use it; we can think through the pros/cons and alternatives. One callout by using the HTML is that currently, the format stored in the HTML does not need to be backwards/forwards compatible since the version of marimo that generated it is the same version in the HTML.

For this issue, whatever "saved outputs" files we create, it will need to be backwards/forwards compatible

[ggggggggg]

Would this help with html output of dynamic components? Such as mo.mpl.interactive() and the rich dataframe display? It would be nice if html output just captured the current view of those, as opposed to showing errors.

[mscolnick]

It would capture the HTML output of those views. likely would end up throwing an error, but we could look into changing the output of mo.mpl.interactive() when output to static html