WARNING: info command does not support starlark options

[mobileink]

Description of the problem / feature request:

The bazel info command prints a WARNING if the .bazelrc file contains starlark options:

$ bazel info output_base
WARNING: info command does not support starlark options. Ignoring options: [--@ocaml//archive/linkall, --@ocaml//executable/linkall, --@ocaml//module/linkall]
/private/var/tmp/_bazel_gar/2cf1b1cbc37d32d28204189d83247676

The options are config settings, e.g. string_flag, 'bool_flag', etc. rules.

Feature requests: what underlying problem are you trying to solve with this feature?

I use bazel info in some shell scripts and this warning message causes problems. The warning itself is not useful anyway.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Should happen for any project with e.g. config setting params in .bazelrc.

What operating system are you running Bazel on?

MacOS 11.3.1

What's the output of bazel info release?

$ bazel info release
WARNING: info command does not support starlark options. Ignoring options: [--@ocaml//archive/linkall, --@ocaml//executable/linkall, --@ocaml//module/linkall]
release 4.0.0

;)

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

$ git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
https://github.com/mirage/ocaml-uri.git
0ff3efbbc235bef5a7d67cc01bc1dadbe2e859b9
0ff3efbbc235bef5a7d67cc01bc1dadbe2e859b9

Have you found anything relevant by searching the web?

Yes, there are a number of bazel issues addressing more or less the same problem, but for the bazel clean command.

[gregestren]

Why not just $ bazel info 2>/dev/null?

By "clean" do you mean #12808?

I'm open to not having the warnings if they're not helpful, but we'd want a broader consensus on that. I'd suggest the stderr redirect in the interim if it's simply a matter of shell script parsing.

[BalestraPatrick]

@gregestren I'm also wondering why this is a warning. Is it possible to have an option apply to all build commands except the ones that don't support starlark options? I don't see an easy way to remove this warning for clean and info commands otherwise.

I also read through #12808 and it seems like the cleanup that removes the implicit inheritance of clean and info from build will take a bit more time. Would you be open for a PR that removes these warnings in the meantime?

[thii]

You can also filter warnings:

clean --ui_event_filters=-WARNING
info --ui_event_filters=-WARNING

[gregestren]

Here's the history: 2ec58f6

I'm guessing the warning is because info output can depend on the configuration. So if it's silently applying a different configuration than expected that's not desirable: https://docs.bazel.build/versions/main/user-manual.html#configuration-specific-data

I'm not sure if any of this could apply to Starlark flags. But that's a reason for caution.

[pauldraper]

To add insult to injury, it doesn't even properly detect Starlark flags.

It warns for --//:custom_flag=false, but errs for --no//:custom_flag.

---

Either info should accept Starlark flags, or there should be a way to pass them to build but not info.

[gregestren]

CC @aranguyen who's been looking into these subtle quirks with --no vs. ...=false and Starlark/native discrepancies recently.

[aranguyen]

@pauldraper this commit should have fixed the issue you mentioned f6cccae . The change is in this release https://github.com/bazelbuild/bazel/releases/tag/6.0.0-pre.20220328.1 . Please let me know if you're still seeing the same issue.

[daixiang0]

@aranguyen still see the same issue:

root:[envoy]$ cat .bazelversion
6.0.0-pre.20220421.3
root:[envoy]$ bazel info
Starting local Bazel server and connecting to it...
WARNING: info command does not support starlark options. Ignoring options: [--@com_googlesource_googleurl//build_config:system_icu=0]  
bazel-bin: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/execroot/envoy/bazel-out/k8-fastbuild/bin
bazel-genfiles: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/execroot/envoy/bazel-out/k8-fastbuild/bin
bazel-testlogs: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/execroot/envoy/bazel-out/k8-fastbuild/testlogs
character-encoding: file.encoding = ISO-8859-1, defaultCharset = ISO-8859-1
command_log: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/command.log
committed-heap-size: 1050MB
execution_root: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/execroot/envoy
gc-count: 3
gc-time: 21ms
install_base: /root/.cache/bazel/_bazel_root/install/105cdae8e95eaae9b55d5e684bad8944
java-home: /root/.cache/bazel/_bazel_root/install/105cdae8e95eaae9b55d5e684bad8944/embedded_tools/jdk
java-runtime: OpenJDK Runtime Environment (build 11.0.6+10-LTS) by Azul Systems, Inc.
java-vm: OpenJDK 64-Bit Server VM (build 11.0.6+10-LTS, mixed mode) by Azul Systems, Inc.
max-heap-size: 3221MB
output_base: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351
output_path: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/execroot/envoy/bazel-out
package_path: %workspace%
release: release 6.0.0-pre.20220421.3
repository_cache: /root/.cache/bazel/_bazel_root/cache/repos/v1
server_log: /root/.cache/bazel/_bazel_root/2d35de14639eaad1ac7060a4dd7e3351/java.log.dev.root.log.java.20220623-062939.537
server_pid: 537
used-heap-size: 176MB
workspace: /workspaces/envoy

[aranguyen]

@daixiang0 it is by the current design that the command info does not support Starlark options, hence you see the WARNING. The commit I mentioned in #13473 (comment) fixed the bug mentioned here #13473 (comment) where Bazel warns for --//:custom_flag=false, but errs for --no//:custom_flag. Bazel should now warns for both.

[anthpi]

From the end-user perspective, he/she provides a flag in .bazelrc file for the build command. As a side-effect, for some reason, those flags are even propagated to clean and info. He/she gets a WARNING that is not very useful as there is no way for the end-user to fix this. You are going to be surprised how many people are still searching for "WARNING" in their logs and fail tests due to that.
I agree with @pauldraper that there should be a better solution. Either to support flags or not send them in.

[josephlr]

This was fixed in #16616 (see b564d14). The info and clean commands no longer warn, and starlark flags have no effect on these commands.

This issue can now be closed.