<@U06A03HV1> I’ve got a rule graph question about ...
# development
@witty-crayon-22786 I’ve got a rule graph question about unions and in_scope_params 🧵
I see that when a rule has a
for a union that ends up as a “re-entry query” node in the graph, due to the presence of
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?
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
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
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
oh, so you should have to be more explicit with what types you need..
right. it’s essentially defining the signature / API for a plugin.
by plugin, do you refer to the set of rules registered by that plugin
so, isn’t that on “another level” as this all is on the rule level..
not sure what you mean
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
hm. i suppose, but i’m not sure that the distinction is meaningful
as it stands, a plugin can essentially only provide itself via
… any
that hook into the graph in any other way aren’t really a plugin
💥 1
…because the graph will fail to compile without them.
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.
sure thing