OUTPUT_MAX_BYTES should be a setting

[liquidcarbon]

HNY!

Just ran into the OUTPUT_MAX_BYTES warning, and it's quite a nuisance IMO.

1. there's no recovering from this helpful message - not great, especially in App mode because it effectively breaks the page till the app is restarted
2. why does it MARIMO_OUTPUT_MAX_BYTES need to be an env var? it's not possible to change it without restarting everything - couldn't it be a setting? what's the idea of separating these rather random settings out into env vars?

marimo supports the following environment variables for advanced configuration:

| Environment Variable          | Description                                                                                                                  | Default Value   |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------- |
| `MARIMO_OUTPUT_MAX_BYTES`     | Maximum size of output that marimo will display. Outputs larger than this will be truncated.                                 | 5,000,000 (5MB) |
| `MARIMO_STD_STREAM_MAX_BYTES` | Maximum size of standard stream (stdout/stderr) output that marimo will display. Outputs larger than this will be truncated. | 1,000,000 (1MB) |
| `MARIMO_SKIP_UPDATE_CHECK`    | If set to "1", marimo will skip checking for updates when starting.                                                          | Not set         |

3. OR could mo._messaging.streams.OUTPUT_MAX_BYTES = 10_000_000 work similarly to pd.options.display (which can be changed upfront in the notebook)?
4. I have indeed produced large output, but it might not have been considered that it is spread across many lazy tabs (altair charts)

[akshayka]

I am fine with all three of these being TOML-driven configuration, in addition to ENV vars, with environment variables taking precedence over TOML config.

[paddymul]

@mscolnick This would really help me for Buckaroo. I was playing in the live WASM playground and I ran up against the limit. Interestingly when I run locally, marimo doesn't complain. Setting the environment variable via os.environ doesn't fix it, because that setting is read at package import time.

My widget has a large JS artifact that is 3 or 3.8MB depending on minimization.

[mscolnick]

first improvement is that we can read this at runtime. there doesn't seem to be a good reason not to

[paddymul]

I'll try to take a swing at a PR on Friday/over the weekend.

Correct me if I'm wrong, but does your PR process create a testing WASM instance to play with?

[mscolnick]

@paddymul, yes it does but i might have to kick it off, which i can

[paddymul]

Sorry for letting this fall out of my attention. Thanks for fixing it. This does fix the bug I was running into when running against the version from the PR https://marimo.app?v=0.11.8-dev2

I still need to do a couple of CSS fixes. When will this be released to your public site?

[mscolnick]

@paddymul, i can do a release today

[paddymul]

Thank you again.

[qgerman2]

for anyone looking to workaround the limit as quickly as possible, you do so per script with this line

import marimo as mo
mo._runtime.context.get_context().marimo_config["runtime"]["output_max_bytes"] = 10000000000