greg and i walked through the current TargetAdaptor construction earlier (and guessed at design motivations) and we have not found any obvious issues (that sounds mean — i meant that we’re coming around to it although it was unfamiliar at first). it seems like part of the result of this architecture is that we’ll never have to have an entire build graph in memory at once (due to lazily hydrating structs and their deps in

hydrate_struct()

?), which seems pretty neat. we discussed how the field_adaptors canonicalize the information extracted from targets and also decouple it from the Target class itself, and we discussed the difference between this and e.g. relying on a class hierarchy (as a thought experiment, nothing more) to do the job of collapsing a mess of duck-typed objects into things that can be fed into our beautiful static rule graph (“mess” doesn’t mean “bad” here). we agreed that there’s some repetition in declaring UnionRules sometimes and @hundreds-breakfast-49010 was thinking we could use some factory or something else that covers more than just linking up a single concrete type to the union at a time. more thoughts were in there too. was a good dive to have today