<@U053HNE90>: I’m not sure how that would work. T...
# general
@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
parameter. I’m beginning to think it may be preferable to use syntax that looks more like:
Copy code
    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
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.