Challenge: Simple command with option or positional argument

[xixixao]

Try to use clap for the following:

Command with both this signature:

command <STRINGS...> <FINAL_STRING>

or

command <STRINGS...> --final STRING

Combined this should be:

command <STRINGS...> <<FINAL_STRING>|--final STRING>

That is either a list of arguments and one argument at the end or a list of arguments and an option.

The challenge is to express this with clap to get correct help and error messages and runtime behavior (the FINAL_STRING argument is required when --final is not provided). Obviously no subcommands. I don't think it's possible.

I think clap is fundamentally too constrained and a bad abstraction. I have thought with it too many times now for commands that go beyond the simple. I think I would be better off with some helpers for parsing and forming help, and moving the actual parsing logic to code.

[epage]

I gave the following a quick try

#!/usr/bin/env nargo
---
[dependencies]
clap = { version = "4", features = ["derive"] }
---
use clap::Parser;

#[derive(Parser, Debug)]
#[command(group = clap::ArgGroup::new("final"))]
struct Cli {
    #[arg(required = true)]
    strings: Vec<String>,
    #[arg(required = true, group = "final")]
    final_string: Option<String>,
    #[arg(long = "final", required = true, group = "final")]
    final_: Option<String>,
}

fn main() {
    let cli = Cli::parse();
    println!("{cli:?}");
}

• Using required on the group isn't recognized for "second to last" processing
• The parser doesn't handle conflicts when deciding whether the last argument should go into strings or final_string

That said, I would be interested to better understand what end-user equirements are driving a this CLI design. For me, this feels a bit out of the ordinary and could cause user confusion because of that.

I think I would be better off with some helpers for parsing and forming help, and moving the actual parsing logic to code.

There are solutions like clap_lex and lexopt if you want to roll your own.

I think clap is fundamentally too constrained and a bad abstraction.

FYI naming this "challenge" and criticizing like this makes it seem like you are more interested in starting an argument than to have a Discussion. Please be respectful in communication.

[xixixao]

Thanks for the answer and apologies about my wording.

[xixixao]

To your question:

The use case is similar to the mv command, but I want the user to be able to choose between renaming and moving into a directory. They can do that via / suffix on the positional argument or by choosing one of the explicit options. The option can also allow changing the order, like mv --into some_dir file_a file_b file_c.

I have ran into similar situations a couple of times with clap, where I spent hours trying to get something to work through a combination of its builtins only to realize it's impossible. It works great for simple cases but I guess I'm pushing the envelope, and because clap has so many features I think it's hard for the library to "correctly" handle all of their combinations.

clap_lex and lexopt look a bit too far on the "implement yourself" scale for me.

[xixixao]

After some more struggle, the best solution for my case I found is to declare two structs, use one to print the help, and the other for parsing.

The help one:

struct HelpCLI {
    #[arg(required(true))]
    source_paths: Vec<String>,
    #[arg()]
    destination_path: String,
    #[arg(short, long)]
    into: Option<String>,
    #[arg(short, long)]
    to: Option<String>,

the one used for parsing:

struct CLI {
    #[arg()]
    paths: Vec<String>,

    #[arg(short, long, conflicts_with("to"))]
    into: Option<String>,

    #[arg(short, long, conflicts_with("into"))]
    to: Option<String>,

    #[arg(short, long)]
    help: bool,
}

Manually combining help:

let raw_args: Vec<String> = std::env::args().collect();
if args.help {
  if raw_args.contains(&"-h".to_string()) {
      help_command.print_help().unwrap();
  } else {
      help_command.print_long_help().unwrap();
  }
  std::process::exit(SUCCESS);
}

I looked at fixing the issue in clap itself, but the parser doesn't seem very amenable to such a fix, without some major reworking. I found it hard to understand, and some of the debug messages confusing (like leaving it to the validator to complain in cases where there is no problem).