Allow setting a Skylark rule kind rather than using "magic" assigned identifier

[shahms]

Description of the problem / feature request:

Currently, when defining a new rule in Skylark the "kind" is essentially part of the public API. It is user-visible through bazel query and BEP but is taken exclusively from the local identifier on the left hand side of the assignment from the rule() function. This (and some documentation examples) easily leads to the mistaken assumption that the rule kind is an internal implementation detail.

Ideally, there would either be another way of setting the rule kind, possibly through an attribute. Barring that the documentation should be much more explicit about the visibility of this name. For example:

_not_really_internal = rule( ... )
my_lang_library = _not_really_internal # Rule kind is "_not_really_internal" which is public.

def my_lang_binary(...): # Also Rule kind "_not_really_internal"
_not_really_internal(..., kind="binary")

Developers (reasonably) assume that they have control over the exposed API based on the "public" identifiers, but this assumption is false when applied to the return value of rule() and this is non-obvious.

Feature requests: what underlying problem are you trying to solve with this feature?

Make the visibility of the rule name more explicit and obvious to developers and maintainers.

[meteorcloudy]

@laurentlb Can you take a look here?

[laurentlb]

cc @c-parsons

[brandjon]

Ideally, there would either be another way of setting the rule kind, possibly through an attribute.

The kind is a property of the rule, not the target, so it would be a parameter to rule(), possibly kind=, or even name= for consistency with targets.

This should be straightforward to implement (modulo a little refactoring) -- we'd basically immediately "export" the rule with the given kind/name, instead of waiting for the post-assign hook.

But the real question is whether it's worth the conceptual complexity to add this feature, and whether there's a demand for it.

[shahms]

Yes, by "attribute" I meant parameter to the rule() function :-)

This confusion over the fairly common source of breakage when rules are refactored (there are a fair few number of bugs and corresponding # Don't change this name or it breaks <things> b/NNNNNN. comments internally.

I suspect making the rule kind explicit would help reduce the conceptual complexity a bit, rather than adding to it. In particular, it provides a very accessible location from which to hang documentation noting that "kind" is used by bazel query and similar facilities along with noting that if omitted it takes the default from the variable assignment. Right now, this fact is kind of buried in an offhand sentence in https://docs.bazel.build/versions/master/skylark/rules.html#rule-creation rather than being visible in the reference documentation for the rule() function, where all of the other configurable parameters are documented.

[brandjon]

See also dup #8640.

[brandjon]

Prioritized because this was identified as useful for migration of native rules to Starlark.

[shahms]

Any update's here? It would be great to at least have the caveats around rule kind more loudly documented :-)