Oh boy .. very cool.

Now how do I do this in bash?

Counterpoint: Yes, parse don't validate, but CLIs should not be dealing with dependency management.

I love Python's argparse because:

• It's "Parse, don't validate" (even supports FileType as a target)
• It enforces or strongly encourages good CLI design
  • Required arguments should in most situations be positional arguments, not flags. It's curl <URL> not curl --url <URL>.
  • Flags should not depend on each other. That usually indicates spaghetti CLI design. Don't do server --serve --port 8080 and server --reload with rules for mix-and-matching those, do server serve --port 8080 and server reload with two separate subparsers.
  • Mutually exclusive flags sometimes make sense but usually don't. Don't do --xml --json, do -f [xml|json].
  • This or( pattern of yours IMO should always be replaced by a subparser (which can use inheritance!). As a user the options' data model should be immediately intuitive to me as I look at the --help and having mutually exclusive flags forces the user to do the extra work of dependency management. Don't do server --env prod --auth abc --ssl, do server serve prod --auth abc --ssl where prod is its own subparser inheriting from AbstractServeParser or whatever.

Thinking of CLI flags as a direct mapping to runtime variables is the fundamental mistake here I think. A CLI should be a mapping to the set(s) of behavior(s) of your application. A good CLI may have mandatory positional arguments but has 0 mandatory flags, 0 mutually exclusive flags, and if it implements multiple separate behaviors should be a tree of subparsers. Any mandatory or mutually exclusive flags should be an immediate warning that you're not being very UNIX-y in your CLI design.

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ - Edit: Ah I see, the author of this article is pointing to this older article too and admits being influenced by it. So never mind.

I'm not sure the value added is worth the extra layer.

I guess my command line options just aren't all that complicated.

I like the concept, and it's great in TS. Unfortunately, not as doable in other languages.

I'm a bit curious if it's possible to extend clap to do this in Rust though (specifically mutually-exclusive arg groups).