https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> I’ve got a rule graph question about ...
# development
c
@witty-crayon-22786 I’ve got a rule graph question about unions and in_scope_params 🧵
I see that when a rule has a 
Get
for a union that ends up as a “re-entry query” node in the graph, due to the presence of 
in_scope_params
it has.
Now, I wonder was union any special before the environments feature, since to me it would seem that this is the one thing that “disconnects” the graph at the rule asking for a type with a union member type as param.
Or rather, I’m wondering if this disconnect was done to satisfy some requirement coming from the environments feature. Iiuc before it would “just” be a fan-out of many dependencies one for each member type of the union for the requested product, right?
w
https://github.com/pantsbuild/pants/issues/12934 had been open for a while, with the goal of having a more explicit API for plugin developers
at various points though, i needed to revisit that issue for performance reasons… because simplifying the solving of unions and bounding what was in scope made graph solving much cheaper
c
Thanks. And with that I assume I got most of the above correctly.. and the driving force here seems to be, performance related, right?
meaning, I don’t see a particular reason for not having all the params in scope all the way?
besides perf
w
with the goal of having a more explicit API for plugin developers
basically, if all params are in scope, a plugin author can’t actually know what is available to them when authoring a plugin, and maintainers can accidentally provide things that shouldn’t be part of the API
c
oh, so you should have to be more explicit with what types you need..
w
right. it’s essentially defining the signature / API for a plugin.
c
by plugin, do you refer to the set of rules registered by that plugin
w
yes
c
so, isn’t that on “another level” as this all is on the rule level..
w
not sure what you mean
c
there’s no concept of plugins, or set of rules now, just a big graph of all the rules. so plugins then, would perhaps be the operation of joining/merging/adding rule graphs together and here I can see plugins being used as a compatibility filter on which graphs may be joined
but the notion of plugins, as I see it, wouldn’t manifest in the tasks them selves
w
hm. i suppose, but i’m not sure that the distinction is meaningful
as it stands, a plugin can essentially only provide itself via 
@unions
… any 
@rules
that hook into the graph in any other way aren’t really a plugin
💥 1
…because the graph will fail to compile without them.
c
ah ok, that’s slightly different from what I imagined
so plugin -> rule graph “hooks”
nvm the last, I’m just pondering. thanks for the inputs.
w
sure thing
Open in Slack
PreviousNext
Powered by