Description
We had talked about swapping the default for 3.0 but punted.
When working on ArgAction
during 3.2, I modeled it after Python's argparse
which only supports overriding, making args_overrides_self
the only behavior for the new actions.
When switching cargo to the new actions, some tests specifically checking for self-conflicts failed. This reminded me that in cargo 1.64.0, --target
switched from a multiple_occurrences(false)
to multiple_occurrences(true)
. This was a switch from an error case to a working case. If args_overrides_self
had been on, it would have been a switch from a working case to a working case, being a change in working behavior.
We decided in 4.0.0 to defer a decision on the behavior and bring back args_overrides_self
, making the new actions behave like the old ones,
So to summarize args_overrides_self(true)
- Allows easy overriding of previous arguments, especially if args/aliases are involved
- e.g.
alias ls='ls -xyz'
would be safe to repeat some of those flagd
- e.g.
- Has compatibility hazards
So should we switch to it being on by default, only on, or maintain status quo?
Notes
- Overriding of self is the exclusive behavior for Python's
argparse
- A user on Zulip thought
args_overrides_self(true)
was set - A user reported the conflict error as a bug
- Most tools Josh has used seem to ignore duplicate flags, at least (e.g.
rm -fffff file
). - And at least some tools silently override option values as well; for instance,
touch -d 'Jan 1 1970' -d 'Dec 31 2400' file
will use the latter timestamp.
Activity
fix(parser): Conflict-with-self is back on by default
fix(parser): Conflict-with-self is back on by default
fix(parser): Allow one-off self-overrides
fix(parser): Allow one-off self-overrides
fix(parser): Allow one-off self-overrides