Bazel: Rule attributes named "licenses" cause Bazel to crash

Created on 21 Jan 2019  Â·  5Comments  Â·  Source: bazelbuild/bazel

Description of the problem / feature request:

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

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

  • Create empty WORKSPACE, license1.txt, license2.txt
  • BUILD:
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
)

What operating system are you running Bazel on?

macOS Mojave 10.14.2

What's the output of bazel info release?

release 0.21.0

Have you found anything relevant by searching the web?

may be related to #6420 in some way

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

—

Replace these lines with your answer.

If the files are large, upload as attachment or provide link.

P3 team-Configurability bug

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:

  • We recognize that the current license support is very Google specific and insufficient for almost all practical uses (including Google's), so we are going to remove it.
  • There is a Google internal effort to build a more powerful license enforcement system purely in Starlark. I am leading that and plan to do it in a way so that almost everything is open source. One of the requirements is that an organization must be able to customize a top level "license enforcement tool" to
    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".
  • I have a PRD for the tooling that I should be able to publish later this month.
  • implementation will happen over the next few quarters.

All 5 comments

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:

  • We recognize that the current license support is very Google specific and insufficient for almost all practical uses (including Google's), so we are going to remove it.
  • There is a Google internal effort to build a more powerful license enforcement system purely in Starlark. I am leading that and plan to do it in a way so that almost everything is open source. One of the requirements is that an organization must be able to customize a top level "license enforcement tool" to
    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".
  • I have a PRD for the tooling that I should be able to publish later this month.
  • implementation will happen over the next few quarters.
Was this page helpful?
0 / 5 - 0 ratings