mscolnick

team effort, but this awesome goes to Trevor

How do you teach the model to use this new API? Wouldn't they be more effective just using the polars/pandas API which is has been well trained with?

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.

it would be awesome if this embedded marimo notebooks that run on WebAssembly (via https://marimo.app/)

1. marimo

It wasn't included in the blog, but marimo also supports a markdown format, in case you're interested:

    marimo edit notebook.md

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.

Looks awesome! big fans of pyodide, congrats on the launch

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.

[1]: https://github.com/marimo-team/marimo

Thanks for sharing these resources

It is much smaller than that, Pyodide is only 2.8mb and the Python stdlib is 2.3mb when zipped

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

marimo has a playground to run notebooks via WebAssembly - similar to Bento - without having to deploy yourself: https://marimo.app/

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.

marimo notebooks support mermaid as well - https://docs.marimo.io/api/diagrams.html#marimo.mermaid

It is a great tool for diagrams

You can now build plugins inside marimo using anywidget (https://github.com/manzt/anywidget).

For reference, we did a Show HN for marimo earlier this year (https://news.ycombinator.com/item?id=38971966).

production != public, in most cases.

If you are making things public, you likely care about more than just a password, which you'll want to push into an auth gateway with oauth support, authZ, rate-limiting, etc.

We do support GitHub Copilot in the pip/conda installable version that you can run locally on your computer. (https://github.com/marimo-team/marimo)

We have considered adding more copilot features for refactoring or text-to-cell.

We have an FAQ on how we differ from Jupyter https://docs.marimo.io/faq.html#faq-jupyter

the main differences: we are reproducible and reactive. we also aim to be more maintainable, reusable, shareable, and interactive.

For JupyterLite: since we are reactive, you can run notebooks entirely as applications (https://marimo.app/l/e9wii1?mode=read). This means you can easily embed these in (or run them standlalone as) interactive documentation or interactive blog posts.

We have light/dark mode. We plan to add other themes (mostly will just be changing colors/radius).

You can inject any css that you want to directly in the notebook, but it is likely hard to style to match your exact website.

Yes, we do!

We’ve been thinking about it (but had no requests for it yet). I will look into adding it this week. If you would want to make the contribution, feel free to jump/chat in the discord.

Correct, it does not depend on Jupyter. It’s built from the ground up with different principles in mind

1. We do have a variable viewer. We have a few helper panels in the bottom left.

2. PDB support is planned and was scoped out yesterday.

Appreciate the feedback!