https://pantsbuild.org/ logo
Join Slack
Powered by
Currently we can eagerly validate fields during BU...
# plugins
e
Currently we can eagerly validate fields during BUILD file parsing by overriding 
Field.compute_value
but we cannot do said same for a 
Target
as a whole. This precludes validating cross-field data until rule execution time and possibly means needing to complicate rule structure in order to DRY up this validation when the validation is in fact universal. A classic example would be mutually exclusive fields but I imagine there are other cases as well. Id there any reason not to introduce a 
validate
hook method on 
Target
called at the end of initialization that could be overridden to provide validation?
Hrm - I guess the FieldSets that use the set of fields that need to be cross-validated is the place to do this. It still could be the case that more than one FieldSet contains - say - two by-definition (not dependent on the rule context they will be used in) mutually exclusive fields ... but a helper function could be used there to perform validation in each FieldSet.
Consider this self-answered: not needed.
For meta-context: the jarring thing here is some of the early focus in rule API decisions being the importance of eager validation. If that is taken to be a holy dictate above all others, you're led to want a 
Target.validate
. I think Targets have never made sense though, so I'm happy with just in time FieldSet validation.
h
Indeed, I have an open ticket for mutually exclusive fields. It'd be great to add, I only haven't gotten to it
The downside of FieldSet validation is that its lazy, which imo is a worse experience. If the validation is cheap, probably better to do eagerly. This is the thinking behind Field validation
e
My realization above though is that, unlike fields, which are self contained, combinations of fields only make sense in the context of a rule requesting the combination. It may be that a rule requests fields 1, 2, 3 and another rule, written later - for emphasis - requests fields 2, 3 and 4 and it turns out the combination of values in 2 & 3 is invalid in its context because if the value in field 4. This again boils down to targets not actually making sense.
👍 2
OK - commented on the ticket. It may just be that the example there is not optimal, but it hits the very problem I describe.
Open in Slack
PreviousNext
Powered by