In a bit of a transitive target API pickle here: If we have a field that can has an "impact" (side effect, I guess?) on transitive targets, where should that field be placed? I've run into these scenarios before, but can't find any examples, so I'll contrive a trivial, fake example while I try to find a precise use case from my archives: Let's say I have a compilation flag that could validly be different per target sources, BUT, when we want to link the compiled sources into a library object, the library requires that all dependencies have the same compiler flag. Is that something where we'd just expect the user to understand the language enough to reconcile that problem? Or would we try to solve it ourself? Or maybe this is where

defaults

or

overrides

come in?

# In order for check to pass, we need some special compile options
cc_sources(
    name="foo",
    compile_options=["magicoption1", "magicoption2"]
)

cc_sources(
    name="bar",
    compile_options=["magicoption2", "magicoption3"]
)

// In order for this library to be built, it requires a certain compile option in all deps
cc_library(
    dependencies=[":foo", ":bar"],
    compile_options??? overrides? 
)

The similarly shaped thing in Pants today is resolves. To build a binary, its transitive dependencies need to all be part of its resolve, if not, error.

+1 on resolves. Stu and I put a lot of thought into the theory and implementation of resolves -- let me know if it'd help to VC about, or share more