Colored + wrapped help menu

[MilesCranmer]

This adds standard colors to the help menus. It also enabled "wrap_text" on the binary so it can stay nicely formatted on narrow terminals.

Note that this default clap coloring automatically detects terminal compatibility before adding colors to the menu.

Before:

After:

[MilesCranmer]

Might be nice to have this on Julia itself too...

[IanButterworth]

Nice

[StefanKarpinski]

Might be nice to have this on Julia itself too...

That seems like it would require either duplicating the clap.rs logic in Julia or something kind of complex and clunky. Maybe Julia could have a --help=json option or something like that which dumps the help data as JSON, which a juliaup wrapper could then parse and reformat using clap.rs. When the juliaup launcher detects that help will be printed, it could skip launching the actual Julia process and just dump the help data. Another possibility since the Julia help data is relatively static, would be that we just ship it with all the other Julia version metadata.

[MilesCranmer]

That seems like it would require either duplicating the clap.rs logic in Julia or something kind of complex and clunky. Maybe Julia could have a --help=json option or something like that which dumps the help data as JSON, which a juliaup wrapper could then parse and reformat using clap.rs.

I think this could work. However, adding --help=json as a permanent option might not be worth it if we move to a better strategy later. For the moment I think it's easier to manually sync them (maybe a CI job could compare them) as this wouldn't expand the API surface.

Another alternative could be a julia-MMtk type approach (JuliaLang/julia#56989) and make a new BinaryBuilder artifact for the help menu. The downside of this is that it would mean the help menu would live outside the source tree.

Probably the cleanest longterm option is clap.rs integration directly in the Julia source tree. I just re-read your answer here -

Then there’s the basic OS runtime stuff. This is written in C and could more plausibly be implemented in Rust. However, a very large amount of this would have to be unsafe. As I said, it’s a very unusual program: it inherently needs to do a lot of unsafe (in the Rust sense) low level memory manipulation and does very little dynamic memory allocation that isn’t subsequently managed by Julia’s own GC. There’s a very small amount of concurrent data structure work, but it’s pretty minimal and unlikely to grow or change too much. Rust could maybe help there, but it seems better to keep the runtime as simple and lowest common denominator as possible, which favors C.

If the rust code were confined to the entrypoint – just clap.rs providing the help menu, shell completions, option parsing, and then passing the validated arguments into Julia – I think this might be a reasonable direction to explore?

[MilesCranmer]

On second thought I don't think --help=json is possible, because clap.rs CLIs are compiled

[StefanKarpinski]

Just replacing the CLI entry-point with Rust would be reasonable, but I think adding Rust to the Julia compilation toolchain may not be a popular move among core devs.

[StefanKarpinski]

But, could be worth a discussion. If the Rust entry-point has enough to recommend it, then could be worthwhile.

[MilesCranmer]

I can definitely vouch for clap.rs being worth it. It’s very well maintained and optimized, with 22,000 direct dependent packages in rust alone. In my view, its existence is a major reason behind the proliferation of rust-based shell tools.

Some key selling points:

• efficient validation of flags and arguments, with automatic fixes suggested (e.g., --startupfile generates a helpful error pointing the user to --startup-file)
• generates detailed shell completions for bash/zsh/fish/pwsh/elvish/nushell (this is at the level of being able to interactively tab through -O 0, -O 1, -O 2, -O 3 in the julia command)
• generates roff man pages
• still gives tiny binaries despite lots of features
• configurable and polished styling that automatically adapts to a wide variety of terminal settings

In general, clap.rs is also super portable and constantly stress-tested across OSes and terminals.

Maybe we trial it in juliaup, and if folks like it (and core devs are open), there could be a discussion about making it the standard entry point?

[MilesCranmer]

@IanButterworth do you think this PR could be merged? This one doesn't add anything new, it's just to enable the text wrapping and color in the existing clap.rs menu for juliaup itself