Optionally warn if a [non `allowMultiple`] option is specified multiple times.
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
In #15508, @[ishaangandhi](https://github.com/ishaangandhi) pointed out it would have been helpful for Bazel to warn them that their various `.bazelrc` files were causing the `--test_tag_filters` option to get specified multiple times. (Bazel's current semantics here are to silently take the last value, i.e. to overwrite the previous value(s). Bazel has always had these semantics afaict from looking over the codebase history.) If we're going to make any usability improvement in this area, I think it'd make the most sense to make usability improvements for all options (that aren't specified as `allowMultiple`, of course), not just `--test_tag_filters`.
My proposal here is a new option (heh) `--behavior_on_overwritten_option=(silent|warn|error)` (default value `silent`, i.e. the current behavior.) Practically it may be a bad idea for this to be a literal physical option. Consider `bazel build --foo=a --foo=b --behavior_on_overwritten_option=warn --bar=c --bar=d`: naively we'd warn only for `--bar`; if we want to warn for `--foo` too the implementation would need to do two passes over all options. So a JVM system property or environment variable or something like that may be a better practical idea. I'll leave that to the eventual assignee to consider.
Note that Bazel's option parsing implementation already has the notion of "priority" (see `OptionPriority.PriorityCategory`). This is the notion of whether an option specified in one manner (e.g. command line) ought to or ought to not take precedence over one specified in another manner (e.g. `bazelrc`). I think this should be an orthogonal notion to my proposal; my proposal is just for options in the same priority category overwriting each other (note how the example in #15508 was `--test_tag_filters` in two different `bazelrc` files, not one in one `bazelrc` file and another on the command line).
### What underlying problem are you trying to solve with this feature?
Make it easier for users to realize they are passing the same option multiple times and causing only the final value to be used.
### Which operating system are you running Bazel on?
N/A
### What is the output of `bazel info release`?
N/A
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
N/A
### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?
```text
N/A
```
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start by tracing Bazel's option-parsing implementation and the OptionPriority.PriorityCategory notion mentioned in the issue, including how values from multiple .bazelrc files are handled. Compare the proposed silent, warn, and error behaviors and determine a complete configuration approach; done means repeated non-allowMultiple options in the same priority category produce the selected behavior without changing the default.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100