Okay, so that means doing something like calling

ensure_str_list

(which iterates over the entire list) on every

compatibility

we encounter when running

./pants filedeps ::

, which never needs

compatibility

. Are you sure that we’re okay with that performance implication? (I know V1 behaves this way) I think I’d advocate for

LazyField

vs.

EagerField

with a default to

EagerField

.

LazyField

is for when you have some light-weight hydration/validation that doesn’t need the engine, like calling

ensure_str_list

. John is correct in diagnosing that the only truly expensive hydration, like reading from the FS, already will need to be

AsyncField

. So, roughly, *

EagerField

-> used by 70% of fields; do nothing more than maybe use a default value, *

LazyField

-> used by 20% of fields; do light weight validation/hydration *

AsyncField

-> used by 10% of fields; do heavy-weight validation