ch-remote: switch from clap's builder API to derive API #7551
Description
Adding more commands with options, flags, and positional arguments to ch-remote causes a lot of boilerplate and multiple code repetitions. Further, there are already inconsistencies with - and _ in the CLI.
By using the derive API, things would be so much more streamlined and it would be much easier to add more commands, options, flags, and positional arguments.
For example, this is very annoying. We (@amphi) are about to add a new --tls-dir option to receive-migration and send-migration as part of our experiments in our fork. This currently requires:
Command::new("receive-migration")
.about("Receive a VM migration")
.arg(
Arg::new("receive_migration_config")
.index(1)
// Live migration with net_fds not supported in ch-remote.
.help("<receiver_url>"),
)
.arg(
Arg::new("tls-dir")
.long("tls-dir")
.help("directory with TLS certificates")
.num_args(1),
),
and a corresponding
matches
.subcommand_matches("receive-migration")
.unwrap()
.get_one::<PathBuf>("tls-dir")
.cloned()
This is far from convenient. With the derive API, we would have a simple
struct ReceiveMigrationCmd {
// ...
tls_dir: Option<PathBuf>,
}
which we can use to parse and access data.