Allow end users to indicate that specific arguments may be ignored if not recognized

[wchargin]

Closing comment:

The proposed solution is fairly specialized but can be built with #1404 and IgnoreErrors (not seeing it marked as deprecated) might be a stop gap.

Closing this in favor of those options. If there is any concern with that, let us know!

---

Make sure you completed the following tasks

• Searched the discussions
  • Relevant: Support for "undefok"? #2314 opened by @josvisser66. That discussion has one
    request to file it as an issue, and one request for more info.
    Here, then, is an issue with more info.
• Searched the closed issues: for unrecognized arguments

Describe your use case

My team distributes two binaries; one written in Python, and one in Rust
with Clap. The Python binary invokes the Rust binary. As we add new
options to the Rust binary, we can’t immediately teach the Python
binary to pass them, because the most recently released version of
the Rust binary would fail with an “unrecognized option” error.

Another use case, as discussed in #2314, involves rolling deployments.
You have a binary at v1.0.0 running in production. You add a flag to it,
but you can’t teach your your prod configs to pass the new flag, because
v1.0.0 will choke if given that flag. Instead, you can change the
configs to pass --undefok=bar --bar=1. On v1.0.0, this will do
nothing; once v1.1.0 is rolled out, the flag value will be honored.

If a project of yours is blocked on this feature, please, mention it explicitly.

Kind of: this would make developing my team’s project (TensorBoard)
notably easier, as noted in the above link, but we have workarounds.

Describe the solution you'd like

The Google flags system has a feature called undefok (read as
“undefined OK”). If your binary myprog uses gflags, and you run

myprog --undefok=bar --foo=1 --bar=2

then:

• if myprog knows about the --bar option, it will interpret the
  option as usual;
• but if myprog does not know about the --bar option, then it will
  be ignored. (Without --undefok=bar, this would be an error that
  there is no known flag by the name bar.)

Note that supporting or passing --undefok=bar does not mean that you
can pass arbitrary unrecognized arguments: --wat=3 would still be an
error.

I imagine that this could be implemented either as a new AppSettings:

let m = App::new("myprog")
    .setting(AppSettings::AllowUndefok)
    .arg(Arg::with_name("foo").long("foo").takes_value(true))
    .get_matches_from(vec![
        "myprog", "--undefok=bar", "--foo=1", "--bar=2",
    ]);

assert_eq!(m.value_of("foo"), Some("1"));
assert_eq!(m.value_of("baz"), None); // arg just ignored

…or as an ArgSettings to allow customizing the magic name undefok:

let m = App::new("myprog")
    .arg(Arg::with_name("foo").long("foo").takes_value(true))
    .arg(Arg::with_name("undefok").long("my-undef-ok").undefok(true))
    .get_matches_from(vec![
        "myprog", "--my-undef-ok=bar", "--foo=1", "--bar=2",
    ]);

assert_eq!(m.value_of("foo"), Some("1"));
assert_eq!(m.value_of("bar"), None); // arg just ignored

Alternatives, if applicable

One heavyweight alternative is to provide a mode in which arbitrary
unrecognized flags are permitted. But this carries too high a cost:
users who make a typo in an option name should be alerted, not have
their inputs silently ignored.

Additional context

IMHO, it’s okay if we need to require that --undefok precede the
undefined arguments on the command line:

--undefok=bar --bar=2  # should be accepted and ignored
--bar=2 --undefok=bar  # it's okay with me if this is rejected

I also imagine that there might be issues distinguishing flags from
options. It’s okay with me if we need to require that any undefok
options use the “stuck” form:

--undefok=bar --bar=2  # should be accepted and ignored
--undefok=bar --bar 2  # it's okay with me if this is rejected

[tmplt]

provide a mode in which arbitrary unrecognized flags are permitted.

This would be useful in programs that extend cargo build. For example, in cargo-flash and cargo-rtic-scope we want to forward unknown arguments to cargo build. At present this is possible with AppSettings:TrailingVarArgs | Appsettings::AllowLeadingHyphens, but it requires cargo options to be passed as the last options. E.g. cargo flash --bin foobar --release [cargo-flash options...] would be invalid whereas cargo flash [cargo-flash options...] --bin foobar --release would be correct, but not immidiately obvious for the end-user.

[epage]

@tmplt another related issue is #1880

[tmplt]

@epage, thanks. The minimal viable solution proposed within would help my case, but it seems that IgnoreErrors has been deprecated.

[epage]

The proposed solution is fairly specialized but can be built with #1404 and IgnoreErrors (not seeing it marked as deprecated) might be a stop gap.

Closing this in favor of those options. If there is any concern with that, let us know!