feature request: ligther installation

[e3rd]

Tyro's codebase is less than 1 MB. But installing it takes 12 MB. If the codebase were smaller, when I use it as a dependency, it would help other people choose it for smaller tasks on lighter machines.

The biggest are the pigments which are used by rich. Could not we make rich optional somehow? If it's used just for the output.

Either put it as an optional dependency

pip install tyro # without rich
pip install tyro[rich] # with rich

Or make an automatic second pip-package tyro light which does not install rich.

pip install tyro-light

Unfortunately, there is no possibility to not-install a dependency with pip.

Both ways are cubersome and demanding, but the prize is good.

What do you say? This is just a discussion :)

[brentyi]

To reduce maintenance effort my initial preference is to avoid having "with rich" and "without rich" versions of the helptext generation, so If we want to make tyro lighter I'd consider a third option actually: try to remove the rich dependency entirely.

We could re-implement the subset of the rich features that we use, look for lighter libraries, or keep a vendored copy of rich that doesn't require pygments.

Does that make sense to you?

[e3rd]

First, let me express my gratitude that you are open to consider solutions. If tyro were the final program and not a library used by many, I have never raised this.

I've crawled the code a bit. Rich is really the only pain, without this, tyro with all the dependencies tooks only 2 MB. It's being used in 2 ( 3 ) files only, in _cli.py in one single function – easy to edit. In _argparse_formatter.py it's scattered amongst several. (As I never worked with rich directly, I am little confused.)
So the maintanence effort when putting something like this does seem to me not only the smallest solution but also the least programming effort. Keeping vendored copy or a lighter library would still add some kilobytes.

try:
	from rich.columns import Columns
except ImportError:
	Columns = DummyMethodToPrintStr()
# Then, we'd split the pytest.yml to run first a non-rich test, then classic test suit.

Moreover, the rich version looks gorgeous, I like it a lot, I don't want to spoil the tyro experience for a non-minimal machine. It seems to me that rich is being used widely so when tyro is integrated in a bigger project, another part of it uses rich / pygments nevertheless, so on a non-minimal machine there is zero overhead. (Pygments has 7 M! downloads a day from Pypi.) Using try-block would allow the automatic enabling, user has nothing to configure. Even if the user uses the tyro minimal tyro bundle or the tyro-light package, they have to install or configure nothing.

However, it's you to decide, I am just a voice from the crowd.

[e3rd]

I've created a fully working version #326 with minimal code change. There are some dummy objects pretending to be rich objects for the case the rich cannot be imported.

It displays ex. black and white:

$ ./program.py --c fds
────────── Value error ────────── 
Error parsing --c: invalid literal for int() with base 10: 'fds'

Argument helptext:
--c INT
(required)

For full helptext, see program.py --help

instead of:

$ ./program.py --c fds
╭─ Value error ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Error parsing --c: invalid literal for int() with base 10: 'fds'                                                                                                                           │
│ ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── │
│ Argument helptext:                                                                                                                                                                         │
│     --c INT                                                                                                                                                                                │
│     (required)                                                                                                                                                                             │
│ ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── │
│ For full helptext, see program.py --help                                                                                                                                                   │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

What do you say? I know that's not ideal but might be a way to go.

[brentyi]

Thanks for the PR @e3rd!

I've been thinking about this and have basically decided that removing rich as a dependency would be nice.

On the approach, my main concern with #326 is just that it would introduce branches in the code that are rarely used. And (perhaps more importantly) I might personally not use them, which is unideal in terms of maintenance incentive alignment.

That said: it looks like a relatively light change, so it's quite attractive from that angle. I'm still weighing it against the heavier change of implementing formatting without rich, where the benefits could be:

• Keep the same nice colors, tables, etc. But use ANSI codes manually.
• Keep consistent experience for all tyro users.
• No need for mental overhead required by tyro[rich] or tyro-minimal.
• We could simultaneously resolve performance bottlenecks: there are some larger systems that rely on tyro where helptext formatting takes hundreds of milliseconds. My guess is we could reduce this to <5ms.

The downside is that this would take longer; is there urgency on your end? I'd expect it to be a part of a version bump to 0.10.0 (or even 1.0.0). I could do it in conjunction with the other (high effort) change I had planned, which is moving away from the argparse-based parsing backend... tyro performance can be a bottleneck on big systems (millions of parameters) because of a combination of argparse and rich limitations, so this actually seems aligned with longer-term project goals.

[e3rd]

branches in the code

Agree, it does not look good.

that rely on tyro where helptext formatting takes hundreds of milliseconds. My guess is we could reduce this to <5ms.

Yess, I've been there. I'm using tyro in a project that relies on interprocess communication. There are a lot of tests and introducing tyro would forced me to change the Popen timeout to 10 s from 3 s. I've been investigating and there is nothing wrong, just the importing takes so long. It's tempting to reduce the init time. This would make tyro shine over the alternatives, I've tried several dozens and some of them lean on rich.

is there urgency on your end

Let's hope it won't take years. Whoa, getting rid of argparse, this is challenging. Can this be subdivided into smaller steps that me or some other people could help you with? If so, it'd be great to not wait for one immense change but one by one – I think it's always better to produce smaller prototypes than lock-in in a huge change. Ex. like releasing version 0.10.0-beta without rich but still with argparse.
If argparse and rich are tightly attached, then ok. Tyro is still the best, there is no alternative to go.

[brentyi]

You're right, we can try some rich migration first. :)

In terms of timeline: I'm possibly overpromising here but the next few weeks is probably doable. I have a mostly working "formatting without rich" feasibility test by Claude here: 3ef1fe1; I don't plan on using this, but it was helpful for getting a sense of the difficulty.

Here's how things look after the change:

It's not a significant pain point of tyro but the import time improvement is nice. Before:

After:

[e3rd]

Wow, that looks promising!! For me, the biggest pain is the storage space and this solves it completely. Eager the here s ome news / issue help requests in the next weeks / months then.

[e3rd]

Just a note. When you'll be leaving argparser, I beg for a feature to be conserved: Now, I can access the parser via extras. I use it to programatically fetch the help text of the fields that failed (that are missing in the CLI).

(The idea behind this is, when a field fails, my library offers a gui window that enables the user to input the missing fields instead of a program exit:. Link just for reference: https://github.com/CZ-NIC/mininterface/blob/dbb171df98a42c81d81629e0fe25ed8e739485be/mininterface/_lib/cli_parser.py#L236 .)

[brentyi]

Now, I can access the parser via extras

Yes! I'm contradicting my anti-branching statement above but my plan is to do something similar to Cappa, where we maintain both backends. The hope is for no breaking changes to get_parser() or our current shtab-based completion generation. We can modify the tests so they all check for consistency between the two, but a custom backend should be much more performant for large projects 🤞

[e3rd]

Oh, I am confused but curious :D

[emcd]

I could do it in conjunction with the other (high effort) change I had planned, which is moving away from the argparse-based parsing backend... tyro performance can be a bottleneck on big systems (millions of parameters) because of a combination of argparse and rich limitations, so this actually seems aligned with longer-term project goals.

Sorry for the off-topic response, but if you're thinking about moving away from argparse, does this mean that the feature request for detecting whether arguments are default or user-supplied has a greater chance of being approved?

Also, as a note in support of a non-Rich variant; this is potentially another way to resolve the problem of the Unicode box-drawing characters crashing Tyro apps in certain Windows terminals, whose default charset is Code Page 1252 rather than UTF-8. (E.g., Git Bash mintty, which is used on Github Windows runners.) . (Rich actually does have an option to use ASCII box-drawing characters instead and we could patch Tyro to use that, but I am not sure what the options are for terminal detection.)

[brentyi]

does this mean that the feature request for detecting whether arguments are default or user-supplied has a greater chance of being approved?

This is actually one of the things that got me thinking about the argparse move. I'm not sure if it'll make #254 easier in the end though, it depends on how the implementation goes... there are some scenarios where we end up maintaining both our own parsing backend and the argparse one (to avoid breaking get_parser() and completion support via shtab) and end up doubling the effort of changes like this. 😬

Unicode box characters: thanks for the reminder on this! Agree that it would be a good time to fix this as well.