<@U02KAN6061E> congrats on replacing all of Pants ...
# developmenth
hundreds-father-404
03/08/2022, 4:16 PM@bitter-ability-32190 congrats on replacing all of Pants to use the new Options API! So much better. Great work 🎉
The only thing that gives me pause before we deprecate the old API in favor of this new one is https://github.com/pantsbuild/pants/issues/10360. We don't need to implement it, but should confirm we can fix using the new API
➕ 2
🙌 4
🙌🏻 1
b
bitter-ability-32190
03/08/2022, 4:17 PMOnly a one or two stragglers left I think!
h
hundreds-father-404
03/08/2022, 4:18 PMcc @witty-crayon-22786 if you have updated thoughts
Note that the solution for context-aware object factories (CAOF)s was to rip it out and replace with the rules-first Target Generator mechanism. I fear if we have to do that here?
I think we could maybe leverage that you already must use the rules API to access a
Subsystemw
witty-crayon-22786
03/08/2022, 5:04 PMyea, i think that the design on the ticket is still accurate.
witty-crayon-22786
03/08/2022, 5:05 PM(just updated it to cross out the second item)
witty-crayon-22786
03/08/2022, 5:06 PMsince options never involve arbitrary code, i think, the rules that hydrate/set options values can stay built in. if we did need to extend to have validation/construction logic for more types, you could do it with a union.
👍 1
witty-crayon-22786
03/08/2022, 5:07 PMbut that seems less likely to be necessary… pushing too much complexity into the options values themselves as opposed to the rules that consume them wouldn’t be great anyway.
h
hundreds-father-404
03/08/2022, 5:20 PMbut that seems less likely to be necessary… pushing too much complexity into the options values themselves as opposed to the rules that consume them wouldn’t be great anyway.Agreed. And you can always define a new wrapper rule that goes from
MySubsystem -> HydratedOptionAsyncField