Allow private attributes as outputs template placeholders

[mboes]

Description of the feature request:

Consider the following rule:

my_rule = rule(
  _my_rule_impl,
  outputs = {
    "conf": "%{name}-%{_version}.conf",
  },
  attrs = { ..., "_version": attr.string(default = "1.0.0") },
)

This definition doesn't work. It fails with:

For attribute 'conf' in outputs: Invalid placeholder(s) in template

The reason is that _version is a private attribute. But citing private attributes in outputs sounds legit to me, since the spec of the outputs is a property of rule that itself has a private attribute. I could work around this problem using declare_file etc, so it sounds to me like an arbitrary limitation that private variables can't be cited in the outputs template.

Environment info

• Bazel version (output of bazel info release): release 0.9.0- (@non-git)

Have you found anything relevant by searching the web?

No relevant GitHub issues that I could find, except possibly #2467.

[brandjon]

This happens because private attributes are internally name-mangled to make them (almost) inaccessible to users in BUILD files. Perversely, you can actually use them in templates if you access them as %{$version} instead of %{_version}. I don't recommend relying on that behavior as we'll surely want to break it (eventually) and use %{_version} instead.

[laurentlb]

Recommendation is to avoid outputs = {...} and instead create the files with ctx.actions.declare_file. This is much more flexible.

[laurentlb]

cc @c-parsons

[ittaiz]

Interesting, where is this recommendation documented? I didn’t know that

…

On Wed, 21 Nov 2018 at 17:45 Laurent Le Brun ***@***.***> wrote: cc @c-parsons <https://github.com/c-parsons> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4366 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIFxpm1QepkVrDd2FJUGPoBpsYTnNQks5uxXUpgaJpZM4RO-Ys> .

[c-parsons]

The document heading for #6241 covers reasons for an imminent deprecation of rule()'s outputs parameter, and links to some best practices.

As such, I think we can close this issue. (Feel free to comment /discuss within #6241 or its document, though!)