Before, if two arguments were required *and* overrode each other, then
`cmd --opt=1 --other=2` succeded but `cmd --other=2` failed despite
ignoring `--opt=1`. Requiring `--opt=1` to be present but unavailable
doesn't help anyone and makes the behavior less predictable.
Now both commands will have the same behavior.
We had two different implementations of conflicts
- Validating conflicts
- Allowing conflicts to override `required`
- Missing members of a group conflicting with each other
- Missing symmetric conflicts (A conflicts with B so B conflicts with
A)
This consolidates their implementations which should fix overriding of
`required`.
This commit updates the man page renderer to use a relative margin
indent for environment variable text instead of appending to the
existing help text.
Signed-off-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
Fixes: #3630
`Command::_build_all` started as an internal function for
`clap_complete` as a stopgap until #2911. Overtime, we've been finding
more cases where this function needs to be called, so now we're going to
fully embrace it until #2911 so people aren't scrared off by the hidden
implementation from using it.
This was inspired by #3602
Comptibility: Though this adds a deprecation which we general reserve
for minor or major versions, this is enough of a corner case that I'm
fine doing this in a patch release.
With the size of our haystacks, it doesn't seem worth pulling in an
extra depedency. Pretty torn on this because nearly anything else will
pull it in (regex, tokio, etc).
While `clap` depends on `clap_derive`, `clap_derive` inherently has a
dependency on `clap` because it generates code assuming at least a
specific clap version. If a new `clap_derive` is used with an old
`clap`, it'll generate code that won't compile.
We've kept things loose because of
- Bad experiences with overly constrained version reqs
- To not force new `clap` versions to release `clap_derive`.
- People should have a lock file anyways
The downsides:
- `cargo install` does not use `Cargo.lock` by default, required
`--locked`
- If we want people to not skip non-patch releases when upgrading, we
need it to not be a pain
In considering the design for this, we want:
- Ability to modify the argment list while maintaining the `Cursor` for
replacements
- Allow picking up subcommand parsing in the middle of short flags
- Ability to peek at the next item to determine if we want to treat it
as a flag or as a value
- Ability to detect started short and long arguments for completions
Longer term, we also want to consider:
- Allowing users to customize the lexer to support different syntaxes
Since we'll need `skip`, it made me wonder how to name `skip` and
`previous` to fit together, so I decided to play with `seek`. Its
probably over kill but wondering if its better.
Before, we had a generic `next` that provided the next item and peeked
at all remaining items. This was to work around the borrow checker for
modifying the position while accessing args.
We've now split `Input` into `RawArgs` and `ArgsCursor` so we don't have
overlapping borrows. This made it so we can split `next` into `next`,
`peek`, and `remaining`.
