https://pantsbuild.org/ logo
Join Slack
Powered by
or… is that the way to declare that you need to in...
# development
w
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
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
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
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
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
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
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
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)
Open in Slack
PreviousNext
Powered by