https://pantsbuild.org/ logo
#development
Title
# development
h

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 PM
Only a one or two stragglers left I think!
h

hundreds-father-404

03/08/2022, 4:18 PM
cc @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
Subsystem
. So we can do whatever pre-processing via rules, right?
w

witty-crayon-22786

03/08/2022, 5:04 PM
yea, i think that the design on the ticket is still accurate.
(just updated it to cross out the second item)
since 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
but 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 PM
but 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 -> HydratedOption
. The
AsyncField
pattern