`attr.string_list_dict` doesn't resolve `select()` calls to values before type checking.

Given a rule with an attribute defined by attr.string_list_dict(), I’d expect the following two stanzas to be equivalent:

foo(my_attr = {"hello": ["world"]})

foo(
  my_attr = {"hello": select({
    "//conditions:default": ["world"],
  })},
)

However, Bazel rejects the second with a type error:

expected value of type 'list(string)' for dict value element, but got select({"//conditions:default": []}) (select)

[jmillikin-stripe]

The workaround is to copy-paste the non-selected part of the dict into multiple select cases. It’s not pretty, but is tolerable at our config sizes.

Given that the attr module has a fixed set of allowed container types, is it practical to special-case select() when used as a key or value of those containers? For example, string_list_dict attrs must be of type Dict<String, List String>> so there’s only so many ways a select could get in there.

[gregestren]

I think the most practical solution remains https://github.com/bazelbuild/bazel-skylib/blob/master/lib/selects.bzl, since it doesn’t deeply mess with Starlark’s type system.

Also see https://docs.bazel.build/versions/master/configurable-attributes.html#or-chaining and the following section.

Going forward, I suggest criteria for opening new bugs includes demonstrating how the skylib approach is insufficient and really evaluating what kind of organization with existing mechanisms is possible before considering enhancements. We really want to lean away from direct support for syntax like described here, even though I get the intuition from the user side (enough that I even prototyped it!).