@bored-art-40741: I’m not sure how that would work. To summarize, we need provided dependencies which are only available before compile-time, and behave intransitively with respect to the classpath. However, despite being intransitive to the classpath, they (and their transitive dependencies) still need to be properly prepared before their dependees (prepared = compiled, resolved, generated, what-have-you). We were discussing having these included via a

provided_dependencies

parameter. I’m beginning to think it may be preferable to use syntax that looks more like:

target(
  scoped_dependencies=[
    scoped(‘provided’, ‘path/to/target:spec’),
    scoped(‘provided’, ‘path/to/target:spec’),
    scoped(‘provided’, ‘path/to/target:spec’),
  ],
)

Which could also support things like “runtime” dependencies without being ad-hoc. I don’t want to add slightly different versions of all existing build graph-related methods, (eg, closure_with_provided), and I don’t want to dramatically upheave the build graph API by adding kwargs like

with_provided=True

to all the method parameters. I think I will instead inject the scoped dependencies as normal dependencies, but filter them after the fact as needed in the tasks that care about them.