https://pantsbuild.org/ logo
Join Slack
Powered by
<@UKQ8DL2PP>: new thread for your question
# development
w
@early-needle-54791: new thread for your question
So in my use case I want to yield a new type ( a collection of requests). The consumer will also need to get a Platform from somewhere therefore that rule will have multiple params but I will only be yielding one from above in the graph. Will that work?
@early-needle-54791: in the case of 
yield Get(ExecuteProcessResult, ExecuteProcessRequest, ..)
, there is an intrinsic (mentioned a bunch of places, including here: https://github.com/pantsbuild/pants/blob/ed2100dd05b83835a6a89aa1e1115d6dc86c81f8/src/rust/engine/src/tasks.rs#L131-L166) that implements that actual node
if you'd like to change the API, you have a few options
1) install another parallel API that uses different types
e
right but I want to add a layer before the Get on ExecuteProcessRequest
w
2) replace that intrinsic with a different one
e
which will itself do the intrinsic request(s)
w
hm ok. that would be closer to 2) then.
basically, you'd change the intrinsic to consume some other type
and then you'd install a python 
@rule
to provide that new type given an 
ExecuteProcessRequest
e
my original question was more broad: if I provide one type in a Get, and have a rule rule that converts that type to the one I want, the only way to get more information into the consumer is to have it reach out and Get whatever it needs. I think I just answered my own question but worth checking with you
w
Not understanding what you mean. But ... yes, I think?
Either the rule continues to provide the same input type and you install a different rule to convert that to your new type
Or you change all consuming rules to provide a different type as input
If you think of this like overloading: if you have a rule that can convert from BasicProcessRequest to AdvancedProcessRequest, then a caller could yield either of those as input with one underlying intrinsic that consumes an AdvancedProcessRequest
e
I think I understand but just for clarity sake my original question restated. Say I yield to some get with a type that has one rule that can consume it and gives me my desired output. That rule cannot take any other argument beside the ones I yield in the Get. So anything else I need (like a Platform) needs to be fetched in the body of the rule with another yield
w
No
That was part of my response to Benjy. A rule can consume anything that is already in the context, so if a Platform came in as a RootRule (or anywhere else above you in the graph), it is available in a subgraph
đź‘Ť 1
e
If you think of this like overloading: if you have a rule that can convert from BasicProcessRequest to AdvancedProcessRequest, then a caller could yield either of those as input with one underlying intrinsic that consumes an AdvancedProcessRequest
Makes sense. I was thinking about it in the other direction…adding an AdvancedProcessRequest that will be yielded from some rules. Then adding an intermediate rule that extracts the correct basic requests from it and gives them to the engine.
w
Althoooough, one complication is that there are currently no intrinsic rules that consume more than one Param. There are plenty of 
@rules
that do though (and take multiple arguments)
@early-needle-54791: re the python rule that extracts the "correct" stuff: I don't think you'd be able to do that from python
Without the python code learning about speculation.
So I expect it's the other way around, as in the overload example
e
Interesting. I was thinking it would just use the target platfrom to extract the requests with the correct constraints, but now that I think about it the way that would work would be to wrap all the matching requests (with potentially different execution platforms) into something that sounds alot like your AdvancedProcessRequest.
so yes. I think were on the same page now!
w
Nioce
Open in Slack
PreviousNext
Powered by