question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

bazelrc: Allow "common" lines to always accept any legal Bazel options

See original GitHub issue

Description of the problem / feature request / question:

Currently, if a bazelrc file contains a common line, then all of the specified options are passed to every bazel command that is run. I propose that the common line always allow all legal options that can apply to any command, but silently ignore the ones that don’t apply to the current command.

The current behavior can easily lead to unnecessary error messages, and greatly hampers the usefulness of the common feature.

For one thing, there are very few Bazel options that are actually common across every command.

Also, although bazelrc supports inheritance (e.g. test and run will automatically inherit from any build lines), that inheritance isn’t always enough. For example, suppose I want to have a custom --package_path for every Bazel command that supports that flag. It’s not sufficient to write

build --package_path ...

because that will apply to build, test, and run, but not to fetch, info, and query, which do not inherit from build but do support the --package_path option.

I could write

build --package_path ...
fetch --package_path ...
info --package_path ...
query --package_path ...

But that is (a) messy, (b) requires me to do a lot of research to carefully figure out which commands support --package_path, and © could break in the future if I upgrade to a newer version of Bazel that supports --package_path for additional commands.

What I really want is to write

common --package_path ...

but I can’t, because that breaks any command that doesn’t support that flag, such as bazel help.

I think probably the best way to address this is what I proposed above: The common line always allows all legal options that can apply to any command, but silently ignores the ones that don’t apply to the current command.

So common --package_path ... would never cause an error, but common --invalid_flag would cause an error.

Environment info

  • Operating System:

OS X

  • Bazel version (output of bazel info release):

0.4.5

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:17
  • Comments:12 (8 by maintainers)

github_iconTop GitHub Comments

2reactions
alexeaglecommented, Nov 19, 2022

I brought up this issue with several groups at BazelCon this year, including the first community day unconference session and the rules authors SIG meeting. There was wide consensus that accidental external repository invalidations and analysis cache discards is a high-priority usability issue. Recent posts on this thread highlight the infeasibility of existing workarounds.

@katre agreed that it’s reasonable to solve this as @mmorearty proposed in the OP: ignore flags that aren’t available on the given command. I believe that is non-breaking for users, since the only behavior change is for bazel invocation that would fail under existing versions of bazel. However he feels that there may be some design discussion required. @gregestren is likely the other expert on this who could help to propose or evaluate designs that can fix it.

0reactions
jesseschalkencommented, Jun 23, 2022

My Bash isn’t great but here is a version of @pauldraper 's script that handles inheritance of options between commands.

bazel-option-commands.bash

#!/usr/bin/env bash

set -e -u -o pipefail

# Commands that don't inherit any options
base_commands=(
  analyze-profile
  build
  dump
  fetch
  help
  license
  query
  shutdown
  sync
  version
)

# Commands that inherit options from build
build_commands=(
  aquery
  canonicalize-flags
  clean
  info
  mobile-install
  print_action
  run
  "test"
  # It is not documented that config inherits from build but it does
  config
)

# Commands that inherit options from test
test_commands=(
  coverage
  cquery
)

option="$1"

all_commands_match=true

function command_has_option {
  local help_content
  if ! help_content="$(bazel help --short "$1")"; then
    exit $?
  fi
  grep -qE "^  --(\\[no\\])?$option\$" <<<"$help_content"
}

function test_command {
  if command_has_option "$1"; then
    echo "$1"
  else
    all_commands_match=false
  fi
}

for command in "${base_commands[@]}"; do
  test_command "$command"
done

if ! command_has_option build; then
  for command in "${build_commands[@]}"; do
    test_command "$command"
  done
fi

if ! command_has_option test; then
  for command in "${test_commands[@]}"; do
    test_command "$command"
  done
fi

if [ "$all_commands_match" = true ]; then
  echo "(all commands match, you can put this in \"common\" in .bazelrc)"
fi
$ ./bazel-options-commands.bash workspace_status_command
build
$ ./bazel-options-commands.bash repository_cache
analyze-profile
build
dump
fetch
help
license
query
shutdown
sync
version
(all commands match, you can put this in "common" in .bazelrc)
Read more comments on GitHub >

github_iconTop Results From Across the Web

Write bazelrc configuration files | Bazel
Options on the command line always take precedence over those in rc files. For example, if a rc file says build -c opt...
Read more >
Commands and Options | Bazel
This page covers the options that are available with various Bazel commands, such as bazel build , bazel run , and bazel test...
Read more >
General Rules | Bazel
The following matches any build that sets --compilation_mode=opt or -c opt (either explicitly at the command line or implicitly from .bazelrc files):.
Read more >
Command-Line Reference | Bazel
Option Syntax; Commands; Startup Options; Options Common to all ... Note: command line options will always supersede any option in bazelrc.
Read more >
User's Guide - Bazel 0.21.0
Bazel allows a number of ways to specify the targets to be built. ... Options specified in the command line always take precedence...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found