Expressing custom module hierarchies / architectures with Bazel

[jerrymarino]

I'd like to know the tradeoffs and ways to get other kinds of rules composing together a rules_ios build graph. Today the common primitive is apple_framework - and they are setup to be dependent on one another.

Consider a package which has an interface module and a sibling Bindings. Bindings are linked deps ( e.g. in the final executable ) and injected at the top of the tree - they are not to be depended by most of the tree. Without support in the build system, today I'd need to add significant amounts of redundant labels and have unmaintainable build files.

To remdiate this - I thought to join them together into a higher order a "bound_module" rule so I can propagate or collect all Bindings further up the tree:

bound_module = rule(
   interface = ":Interface",
   bindings = ":Bindings"
   # Other idioms here
)

You can of course pull something like this off in starlark - but ideally we harden everything to deal with this. Perhaps with such hardening we can support it end to end in project generation and testing without requiring a user to explicitly deal with todays providers or related code. On the other hand, it might be nice to codify such "glue" rules