Skip to content
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

'bazel info' reports 'unknown key' error for .bazelrc with Starlark flag #11301

Closed
jayconrod opened this issue May 6, 2020 · 2 comments
Closed
Assignees
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Configurability platforms, toolchains, cquery, select(), config transitions type: bug

Comments

@jayconrod
Copy link
Contributor

Description of the problem / feature request:

If the workspace's .bazelrc has a flag that sets a build setting defined in Starlark, bazel info fails with ERROR: unknown key. If bazel info is given an argument, it fails with at most one key may be specified.

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

In the example workspace below, run bazel info or bazel info output_base.

-- WORKSPACE --
# empty file

-- BUILD.bazel --
label_flag(
    name = "example",
    build_setting_default = "WORKSPACE",  # default doesn't matter
)

-- .bazelrc --
build --//:example=//:WORKSPACE
$ bazel info
ERROR: unknown key: '--//:example=//:WORKSPACE'
$ bazel info output_base
ERROR: at most one key may be specified

What operating system are you running Bazel on?

macOS / amd64 10.15.4

What's the output of bazel info release?

ERROR: at most one key may be specified

If the .bazelrc file is removed or commented:

release 3.1.0

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

Originally reported in bazel-contrib/rules_go#2475.

I switched rules_go's static analysis framework to using Starlark flags and configuration transitions. I'd like to recommend that users put the default static analysis binary in .bazelrc:

build --@io_bazel_rules_go//go/config:nogo=@io_bazel_rules_go//:tools_nogo

cc @katre @gregestren @juliexxia

@jin jin added team-Configurability platforms, toolchains, cquery, select(), config transitions type: bug untriaged labels May 7, 2020
@gregestren gregestren added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels May 18, 2020
@gregestren
Copy link
Contributor

@juliexxia is investigating. We believe there's a fast fix for this.

@juliexxia
Copy link
Contributor

It seems like bazel info doesn't need to know about build settings at all, so working on a change to ignore them for the info command.

apattidb pushed a commit to databricks/bazel that referenced this issue Dec 8, 2020
Related: bazelbuild#11301
(Fixed in bazelbuild@2ec58f6)

Motivation:

`StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
into account where the specified Starlark option has a value, e.g.
`--//my_rules/custom_flags:foo=bar`.

Modifications:

- Do not pass a Starlark flag value when validating the flag name.

Result:

`bazel info` does not fail anymore when `.bazelrc` contains a statement
like the following:

    build --//my_rules/custom_flags:foo=bar
bazel-io pushed a commit that referenced this issue Dec 22, 2020
Related: #11301
(Partially fixed in 2ec58f6)

Motivation:

`StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
into account where the specified Starlark option has a value, e.g.
`--//my_rules/custom_flags:foo=bar`.

Modifications:

- Do not pass a Starlark flag value when validating the flag name.

Result:

`bazel info` does not fail anymore when `.bazelrc` contains a statement
like the following:

    build --//my_rules/custom_flags:foo=bar

Closes #12648.

PiperOrigin-RevId: 348676049
katre pushed a commit that referenced this issue Jul 12, 2021
Related: #11301
(Partially fixed in 2ec58f6)

Motivation:

`StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
into account where the specified Starlark option has a value, e.g.
`--//my_rules/custom_flags:foo=bar`.

Modifications:

- Do not pass a Starlark flag value when validating the flag name.

Result:

`bazel info` does not fail anymore when `.bazelrc` contains a statement
like the following:

    build --//my_rules/custom_flags:foo=bar

Closes #12648.

PiperOrigin-RevId: 348676049
katre pushed a commit to katre/bazel that referenced this issue Jul 13, 2021
Related: bazelbuild#11301
(Partially fixed in bazelbuild@2ec58f6)

Motivation:

`StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
into account where the specified Starlark option has a value, e.g.
`--//my_rules/custom_flags:foo=bar`.

Modifications:

- Do not pass a Starlark flag value when validating the flag name.

Result:

`bazel info` does not fail anymore when `.bazelrc` contains a statement
like the following:

    build --//my_rules/custom_flags:foo=bar

Closes bazelbuild#12648.

PiperOrigin-RevId: 348676049
katre pushed a commit to katre/bazel that referenced this issue Jul 13, 2021
Related: bazelbuild#11301
(Partially fixed in bazelbuild@2ec58f6)

Motivation:

`StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
into account where the specified Starlark option has a value, e.g.
`--//my_rules/custom_flags:foo=bar`.

Modifications:

- Do not pass a Starlark flag value when validating the flag name.

Result:

`bazel info` does not fail anymore when `.bazelrc` contains a statement
like the following:

    build --//my_rules/custom_flags:foo=bar

Closes bazelbuild#12648.

PiperOrigin-RevId: 348676049
katre pushed a commit to katre/bazel that referenced this issue Jul 13, 2021
Related: bazelbuild#11301
(Partially fixed in bazelbuild@2ec58f6)

Motivation:

`StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
into account where the specified Starlark option has a value, e.g.
`--//my_rules/custom_flags:foo=bar`.

Modifications:

- Do not pass a Starlark flag value when validating the flag name.

Result:

`bazel info` does not fail anymore when `.bazelrc` contains a statement
like the following:

    build --//my_rules/custom_flags:foo=bar

Closes bazelbuild#12648.

PiperOrigin-RevId: 348676049
luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this issue Sep 4, 2022
    Related: bazelbuild/bazel#11301
    (Partially fixed in bazelbuild/bazel@2ec58f6)

    Motivation:

    `StarlarkOptionsParser.removeStarlarkOptions()` doesn't take the case
    into account where the specified Starlark option has a value, e.g.
    `--//my_rules/custom_flags:foo=bar`.

    Modifications:

    - Do not pass a Starlark flag value when validating the flag name.

    Result:

    `bazel info` does not fail anymore when `.bazelrc` contains a statement
    like the following:

        build --//my_rules/custom_flags:foo=bar

    Closes #12648.

    PiperOrigin-RevId: 348676049
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Configurability platforms, toolchains, cquery, select(), config transitions type: bug
Projects
None yet
Development

No branches or pull requests

4 participants