https://pantsbuild.org/ logo
Join Slack
Powered by
I'm writing a test for a rule that eventually depe...
# development
h
I'm writing a test for a rule that eventually depends on TransitiveHydratedTargets, and it provides BuildFileAddresses for that purpose. It looks like those BuildFileAddresses have to correspond to actual underlying BUILD files on the filesystem? Otherwise during the transitive hydration I get: ``````
a
how else are you getting these BuildFileAddresses if not from BUILD files on the filesystem?
h
I'm giving a TargetAdaptor that I create programmatically in the test, but I see your point
My question makes no sense
So in the test presumably I write a BUILD file and some source files etc. Then how do I get a TargetAdaptor from those? I could create one programmatically, but it would be repetitive.
a
so the way we actually create `TargetAdaptor`s anyway is repetitive
it starts off as just a blob of what's essentially json (the 
kwargs()
s from the BUILD file)
then we "hydrate" them with `HydratedField`s to create a 
HydratedTarget
, by actually calling the `TargetAdaptor`'s constructor again, with new kwargs obtained via hydration
so to me the act of creating a new 
TargetAdaptor
programmatically seems extremely reasonable
i will link you to where the re-construction of the 
TargetAdaptor
occurs
look at the 
type(target_adaptor)(**kwargs)
, and how 
kwargs
is constructed from the previous kwargs, adding the 
hydrated_fields
as new kwargs on top of that, then directly re-creating the target adaptor by getting its type
Untitled
so creating a 
TargetAdaptor
can be done like that, or just with 
TargetAdaptor(**the_kwargs_i_want_to_inject_as_if_it_was_in_a_real_BUILD_file)
this is not the only way to do this, but i think creating `TargetAdaptor`s is a pretty cool idea and was thinking about that this weekend
and this is also why i said that `TargetAdaptor`s are essentially json when they're parsed from BUILD files
and could even be serialized like that!
w
if you have actually written BUILD files, you can add the set of rules that would support actually parsing them
a
i continue to be excited about the idea of a BUILD file as convertible to json or something
we could use graphql
w
don't tell anyone, but we already support parsing BUILD files as json and yaml =P
a
oh ok
that's incredibly cool
Open in Slack
PreviousNext
Powered by