This issue will track the tasks for migrating Lighthouse from clap builder to derive.

Clap derive offers some nice features including

• type casted flag definitions, no need to do any post processing to the flag values i.e. converting strings to other types
• easier to read flag definitions

Clap derive is a bit less flexible than the builder, but its possible to combine the builder with derive if needed. All of our flag definitions today are fairly "standard", so derive shouldn't cause any issues.

Another nice bonus with clap derive is it should make ingesting a config at startup easy. Its fairly trivial to map a json,yaml,whatever file to a struct. And the clap derive flag definitions are structs. An example might make things a bit clearer.

Take this function that parses cli arguments and returns some config that Lighthouse then uses to do stuff

fn parse_client_config<E: EthSpec>(
    cli_args: &ArgMatches,
    _env: &Environment<E>,
) -> Result<ClientConfig, String>

With clap derive, instead of passing in the cli args, we pass in the struct that defines those cli args

fn parse_client_config<E: EthSpec>(
    database_manager_config: &DatabaseManager,
    _env: &Environment<E>,
) -> Result<ClientConfig, String>

It then becomes straight foward to write some code that maps a provided yaml,json,etc file to an instance of DatabaseManager and feed that into the same parse_client_config function. Were now re-using the same code paths that ingest cli params from the command line to ingest cli params from a file.

Tasks

• allow for mixing clap derive subcommands within a builder parent command Change DB Manager Clap usage to derive #5898
• database manager Change DB Manager Clap usage to derive #5898
• beacon node
• validator client Migrate validator client to clap derive #6300
• account manager Migrate account manager cli client to clap derive #6493
• validator manager @macladson
• migrate lighthouse main to derive
• Ingest config file at start up