Rule with attribute named "licenses" and defined default value will cause bazel to crash, log attached
Having a rule which needs to take in licenses attribute with type label_list
WORKSPACE, license1.txt, license2.txtBUILD:exports_files(["license1.txt", "license2.txt"])
filegroup(
name = "license_files",
srcs = ["license1.txt", "license2.txt"],
visibility = ["//visibility:public"]
)
load("//:rules.bzl", "sample_rule")
# WORKS
sample_rule(
name = "x",
licenses = [":license_files"]
)
# DOESN'T WORK
# (uncommenting breaks building _any_ target)
"""
sample_rule(
name = "y",
)
"""
rules.bzl:
def _sample_rule_impl(ctx):
ctx.actions.run_shell(
inputs = [],
outputs = [ctx.outputs.out],
command = "touch {}".format(ctx.outputs.out.path)
)
sample_rule = rule(
attrs = {
"licenses": attr.label_list(
allow_files = True,
default = ["//:license_files"]
)
},
outputs = {
"out": "%{name}.txt"
},
implementation = _sample_rule_impl
)
macOS Mojave 10.14.2
bazel info release?release 0.21.0
may be related to #6420 in some way
—
Replace these lines with your answer.
If the files are large, upload as attachment or provide link.
Hi @vmax, thank you for reporting the issue!
My guess is that as a workaround you could rename "licenses" attribute into something, like "licenses_".
Assigning to team-Starlark, because we should warn the user about such cases of names ovelapping.
@irengrig
My guess is that as a workaround you could rename "licenses" attribute into something, like "licenses_".
Thank you, this is the solution I applied
Nicely detailed report, thank you.
This is definitely related to https://github.com/bazelbuild/bazel/issues/6420. The ultimate solution is to strip this out as anything special vs. any other attribute.
https://github.com/bazelbuild/bazel/issues/6420#issuecomment-436675362 mentions a timeline which prefers not doing this until a new licensing mechanism is in place.
But an active crash isn't innocuous - that seems worth fixing now to me. Assigning to @aiuto, who's leading removal / replacement of all things licenses.
Lowering to P3 because there is an easy workaround AND our plan is to eliminate licenses() and replace with a rule set.
Quick note on that:
Most helpful comment
Lowering to P3 because there is an easy workaround AND our plan is to eliminate licenses() and replace with a rule set.
Quick note on that:
enforce the particular mixing (or not) of licenses they care about. We will provide a sample enforcer for guidance. Another way to say that is "one size absolutely does not fit all".