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

witty-crayon-22786

05/21/2020, 1:00 AM
or… is that the way to declare that you need to install a
@rule
to produce Addresses? … ie should that be the union here…?
h

hundreds-father-404

05/21/2020, 1:04 AM
I don’t know what this means. Reminder that 98% of fields are PrimitiveFields and never use the engine. There, we use subclassing to achieve goals like: * set default values * add extra validation * act as a sentinel, e.g. so call sites can distinguish between
PythonBinarySources
vs.
PythonTestsSources
* override the
alias
* override the docstring
w

witty-crayon-22786

05/21/2020, 1:06 AM
the thought would be that
Dependencies
would be a
@union
and you request
Addresses
for members of that union
await Get[Addresses](Dependencies, tgt[Dependencies])
which, for each distinct member of the union, would require a rule to compute
Addresses
h

hundreds-father-404

05/21/2020, 1:14 AM
for each distinct member of the union, would require a rule to compute Addresses
That is something I am trying very actively to avoid. Like with hydration of sources, we don’t want every subclass to need to implement its own rule. Hydrating sources + hydrating dependencies are standard mechanisms, unlike, say how to implement a particular code generator. Instead, the `AsyncField`s expose hooks to add functionality. For example,
Sources
has a
validate_snapshot
method that will get called in the single rule, which allows subclasses to add validation. For
Dependencies
, we will have a hook to inject new dependencies. -- This is really important to get dep inference working correctly. We want that logic centralized into one rule and make it impossible for plugin authors to accidentally mess things up. We also want to avoid plugin authors from ever needing to write a rule for how to hydrate their field, unless they for some reason have a custom
AsyncField
. The Target API is meant to be a simple declarative interface for plugin authors.
w

witty-crayon-22786

05/21/2020, 1:17 AM
yea. “every” subclass of a particular field needing a rule declared for hydration would be a bit much.
👍 1
sorry, still spitballing (almost done, heh):
is it possible that fields themselves should mostly not be subclassed, and instead some sort of field validator would be subclassed…?
so you would only define a “new” field if you needed hydration logic, but otherwise you would install a validator…?
h

hundreds-father-404

05/21/2020, 1:19 AM
sorry, still spitballing (almost done, heh):
Hehe that’s okay. It took me a long time to figure out things like the above. And I think it took me a couple PRs to get right. Also worth stress testing this, as an integral API
is it possible that fields themselves should mostly not be subclassed, and instead some sort of field validator would be subclassed…?
I don’t think so. See https://pantsbuild.slack.com/archives/C0D7TNJHL/p1590023083367900?thread_ts=1590022825.366400&cid=C0D7TNJHL The sentinel thing is an important use case, for example. That’s how in a Field-driven API we have rules signal what targets they are compatible with. For example,
pytest_runner.py
doesn’t say it needs
PythonTests
target, it only needs
PythonTestsSources
.
w

witty-crayon-22786

05/21/2020, 1:24 AM
That’s how in a Field-driven API we have rules signal what targets they are compatible with.
sortof… we don’t actually use the output type. we just match it
ok, anyway, i have to make dinner: thank you for the discussion!
❤️ 1
h

hundreds-father-404

05/21/2020, 1:27 AM
Sg. I got
Dependencies
being an
AsyncField
working, and now just need to fix some tests 😎 call sites aren’t actually much more boiler-platey! And this should be all we ever have to do for the call sites to work with codegen synthetic deps + dep inference! (Unless we care about precise dependencies for codegen)