Support bazel-version specific flags in bazelrc

[rickeylev]

Description of the feature request:

When a project supports multiple Bazel versions, or is straddling two bazel versions during an upgrade, it can be tough to set flags that only exist in particular Bazel versions. This is because Bazel will (quite reasonably) fail with an error when given an unrecognized flag.

To address this, it would be much easier if the bazelrc syntax supported a way to only use lines for particular bazel versions. A couple proposals for addressing this:

(1) try-import-version $version_string $config_file Only import the named config file if the version string matches. e.g. try-import-version 7.4 %workspace%/bazel7.4.bazelrc

The nice thing about this is it could, if desired, later be expanded to have simple operators. e.g. try-import-version >=7 ...

(2a) if-supported <FLAGS> Similar to the common psuedo-command, a flag is only used if bazel recognizes it. e.g. if-supported --some-bazel-flag

The nice thing about this is it works by feature detection.

(2b) --undefok <flag> Similar to how --undefok works in absl: if the flag is recognized, parse it; if not, ignore it. e.g. common --undefok --someflag. This is often used so that flags can be set for programs before a flag is supported, which allows easier rollforward/rollback of binaries.

(3) --enable_bazel_version_specific_config When enabled, bazel automatically adds e.g. --config=bazel7.4 (but doesn't fail if no such config exists). This is similar to the --enable_platform_specific_config flag.

The nice thing about this is it fits neatly into the existing way rcs can include each other.

Which category does this issue belong to?

CLI

What underlying problem are you trying to solve with this feature?

Trying to manage bazelrc file while supporting multiple bazel versions.

Which operating system are you running Bazel on?

Multiple

What is the output of bazel info release?

7.3.2

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 HEAD ?

n/a

Have you found anything relevant by searching the web?

Some related prior art:

• common allowing unrecognized options: Fix common .bazelrc behavior for flag expansions #20720
• automatic host platform-specific flags: Allow platform-specific startup options #22763
• env vars in bazelrc: Use environment variables in .bazelrc via string interpolation #10904

Any other information, logs, or outputs that you want to share?

No response

[meisterT]

Does always warn or fail? cc @fmeum

[meisterT]

cc @gregestren as this might also be a requirement for project.SCL files.

[fmeum]

Does always warn or fail? cc @fmeum

always fails, common ignores silently

[rickeylev]

Thought of a perk the if-supported idea has: it could also be applicable to starlark flags. This then gives users a way to handle the same situation when upgrading rules.

[meisterT]

common does only ignore silently if the flag exists for other commands

[adam-azarchs]

if-supported also means you don't have to hunt through release notes to figure out which minor version of bazel added the flag of interest. It's a bit dangerous, though, because it could hide typos, and you might not remember to switch back to e.g. common when no longer necessary, so you might not notice if that flag gets removed in a future version.

The other problem is that it doesn't actually satisfy all use cases, for example if there's a flag that exists in some version of bazel but is broken in some way, or if you want to use some flag that's existed for a while but you only if you can also use some other flag that hasn't.

I like (3) for similarity to existing prior art (--enable_platform_specific_config), but the main issue I see with it is how does one define appropriate version ranges for it? You don't want to have to specify every possible X.Y.Z version, but there are definitely times when some flag is broken prior to some Z release. You could say that --enable_bazel_version_specific_config on bazel version 7.3.2 would be equivalent to --config=bazel7 --config=bazel7.3 --config=bazel7.3.2 --config=bazel7.3.1 --config=bazel7.3.0 and maybe so on with 7.2.Z, 7.1.Z, etc, e.g. like the ^ constraint in npm, but those semantics start getting ugly. A way to get around that would be something like --config-if-version=min[,max]=bazel7.3.

[rickeylev]

how could --enable_bazel_version_config define ranges?

Maybe just keep it simple? Bazel adds 3 configs --config=X --config=X.Y --config=X.Y.Z (but it only adds ones where the config name exists).

If you need e.g. 7.0-7.3, then you just have to define 3 configs. A bit verbose, but not too bad. Config inclusion handles a lot of it.

build:bazel7.0 --config=bazel7_0_to_3
build:bazel7.1 --config=bazel7_0_to_3
build:bazel7.2 --config=bazel7_0_to_3
build:bazel7.3 --config=bazel7_0_to_3

[adam-azarchs]

Yes, that would work. Starts drifting towards "complicated to explain," however.

Another question I'd have is how does this interact with versions of bazel built from source at some untagged version? e.g. skylib's versions library will just return 999999.999999.999999 for development versions, which is fine for >= constraints but doesn't really work for this. I think bazel internally just has an empty string there. I think it's fair to ignore such things for many kinds of features, but this particular feature does seem like it would be particularly important to support for in-development versions.

[meteorcloudy]

Maybe fixing bazelbuild/continuous-integration#2080 could avoid the need of this feature to some extend?

[rickeylev]

It would mostly solve it for the projects part of Bazel's CI, yes. I filed this FR for the more general case. It's also easier to do local testing when the extra settings aren't in CI configs.

[meteorcloudy]

I guess many people won't like making bazelrc more complicated. But even say we implement this at Bazel@HEAD, we would have to backport this to every minor Bazel versions otherwise something like build:bazel7.1 will never be triggered automatically, right.