Document behavior of custom env and env_inherit attributes in Starlark rules
#12758
Assignees
Comments
meisterT
pushed a commit
that referenced
this issue
Jan 12, 2021
This avoids unexpected behavior in the case of Skylark rules that happen to use the same attribute names. Fixes #12758 PiperOrigin-RevId: 349587545
ulfjack
pushed a commit
to EngFlow/bazel
that referenced
this issue
Mar 5, 2021
This avoids unexpected behavior in the case of Skylark rules that happen to use the same attribute names. Fixes bazelbuild#12758 PiperOrigin-RevId: 349587545
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
eb5cdcb added built-in
envandenv_inheritattributes that control the environment of an executable target in ablaze runinvocation. It's still possible to define these attributes in custom rules. If that happens, and if they are of the right type (strict dict and string list), they will be interpreted specially, probably contrary to the rule author's intent.The clearest thing to do would be to prohibit these attribute names in Starlark rules now that they have special meaning. But that's a breaking change and possibly overkill. We should at least document this unintended interaction.
+@katre as reviewer of that change. (label
team-Starlark, but reallyteam-BuildLanguage, which we haven't created yet.)The text was updated successfully, but these errors were encountered: