[wip] feat: add CLI args to control UI elements when running notebook as script

[eckp]

📝 Summary

WIP: Add parameter to ui element instantiation, to set default value from command line interface argument.

To give control over ui element values when running notebook as script, solving this question.

🔍 Description of Changes

1. Expose mo.raw_cli_args() similar to mo.cli_args(), but keep them as list of str instead of pre-parsing them into a dict to preserve lists as values (circumventing parse_args limitations).
2. Create a global argparse.ArgumentParser object in mo.ui._impl.input.py, to which each ui element can add its argument if cli_name is given.
3. If the argument has a value, update the default ui element value.

📋 Checklist

• I have read the contributor guidelines.
• For large changes, or changes that affect the public API: this change was discussed or approved through an issue, on Discord, or the community discussions (Please provide a link if applicable).
  • Applicable to mo.raw_cli_args()?
• I have added tests for the changes made.
• I have run the code and verified that it works as expected.

📜 Reviewers

@mscolnick

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
marimo-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 16, 2025 9:50pm
marimo-storybook	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 16, 2025 9:50pm

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[eckp]

I have read the CLA Document and I hereby sign the CLA

[mscolnick]

we've actually talked about adding keys to UI elements, as it will have other use cases.

another option that you can do today, why not initialize this with mo.ui.number(value=mo.cli_args().get("test"))?

[eckp]

I like `key`, will use that. Which other use cases does it have? Didn't find any issue or discussion regarding this yet. The current `cli_args()` parsing does not support lists as values, which I would need to support cli-defaults for `mo.ui.range_slider`. Hence my workaround was to have an unparsed version `raw_cli_args()`. However, that does not need to be exposed all the way, could keep it private to `runtime` for example.

…

On March 14, 2025 12:17:20 AM GMT+01:00, Myles Scolnick ***@***.***> wrote: @mscolnick commented on this pull request. > + +__generated_with = "0.11.19" +app = marimo.App(width="medium") + + ***@***.*** +def _(): + import marimo as mo + + mo.raw_cli_args() + return (mo,) + + ***@***.*** +def _(mo): + b = mo.ui.number(cli_name="test") we've actually talked about adding `key`s to UI elements, as it will have other use cases. another option that you can do today, why not initialize this with `mo.ui.number(value=mo.cli_args().get("test"))`? -- Reply to this email directly or view it on GitHub: #4097 (review) You are receiving this because you authored the thread. Message ID: ***@***.***>

[mscolnick]

@eckp, CLI args does support lists. mo.cli_args().get_all("key"). if you find it is broken, can you try to come up with a test case / repro?

[eckp]

Example file test.py:

import marimo as mo
print(mo.cli_args())
print(mo.cli_args().get_all('range_slider'))

yields

$ python test.py --range_slider 5 6 -v
{'range_slider': '5 6', 'v': ''}
['5 6']

so cli_args() does not support lists as values (as indicated here).

While we can parse the string into two separate ints before setting them as default value on the user side:

print(raw_value := mo.cli_args().get_all("range_slider")[0])
print(parsed_value := [int(v) for v in raw_value.split(" ")])
mo.ui.range_slider(0, 10, value=parsed_value)

$ python test.py --range_slider 5 6 -v
5 6
[5, 6]

I thought it would be nice to encapsulate this logic directly inside the UI element, and rely on argparse to return the list of values.

Additionally, we could use argparse to generate a help message for the cli from the UI element's label, limits, etc.

If this sounds useful, I'll proceed with expanding this to other UI elements and adding tests.

[mscolnick]

You need to use the arg twice to the get the list values.

[eckp]

You need to use the arg twice to the get the list values.

Thanks, that works!

I still see value in integrating a cli option in the ui in- and output elements themselves, as it fits the idea of deploying marimo notebooks as a pure python script in a production pipeline, without any boilerplate code on user side.

Do you see a way forward for this idea? If so, feedback on the current draft would be very welcome.
Also, I'd be curious about the other uses of the key arg for compatibility considerations.

[mscolnick]

@eckp, by doing it in user code, the user can validate or transform the CLI inputs. also it's readable by the end-user what is going on.

i don't there is us much more boiler plate:

mo.ui.text(key="input")
# vs
mo.ui.text(value=mo.cli_args().get("input"))

---

Another idea for key i thought of was a way to keep values in sync

mo.ui.number(key="age")
mo.ui.slider(key="age")