-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support bazel-version specific flags in bazelrc #24043
Comments
Does |
cc @gregestren as this might also be a requirement for project.SCL files. |
|
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.
|
|
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 ( |
Maybe just keep it simple? Bazel adds 3 configs 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.
|
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 |
Maybe fixing bazelbuild/continuous-integration#2080 could avoid the need of this feature to some extend? |
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. |
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 |
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 thecommon
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
returnsdevelopment 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
?Have you found anything relevant by searching the web?
Some related prior art:
common
.bazelrc
behavior for flag expansions #20720Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: