https://pantsbuild.org/ logo
Join Slack
Powered by
<@U051221NF> if we proceed with `./pants peek` hyd...
# development
h
@happy-kitchen-89482 if we proceed with 
./pants peek
hydrating async fields, like evaluating the 
sources
field, then I think there's less value for 
./pants filedeps
? They now do the same thing, minus having to extract the info from JSON
A difference would be 
BUILD
not showing up anymore, which it does in 
filedeps
. But imo there isn't a ton of value to that?
w
there is value in filedeps for the super simple case.
imo
h
If we switch peek to operate on generated targets then what does evaluating sources mean? The generate targets already have their sources explicitly set
w
the lists will always be equivalent
i think that the 
sources
example makes a clearer case for using the same field name, but toggling whether it’s expanded or not
h
I disagree, for two reasons: 1) it may be useful to see both, and 2) it's confusing to have the same field name mean two different things, it means that given a JSON blob you have to know the context in which it was produced to interpret it
I don't understand what you mean by "the lists will always be equivalent"?
w
generated targets are generated from sources which have already been expanded
so the input and output will be a literal file path.
h
If 
peek
operates on 
Targets
instead of 
UnexpandedTargets
then in the python case every target has exactly one source file
Right, so there is no point in expanding the sources
they are already expanded
w
if the target is addressable, you’ll need to be able to display it
h
Unless you are suggesting that `Targets`` vs 
UnexpandedTargets
should itself be optional
Today at least 
Targets
replaces the generators with the generated
so you don't see the generators
h
generated targets are generated from sources which have already been expanded
Not true for languages like Go with 
go_package
though. Expanding sources is still a thing for some languages
w
that’s not what 
peek
is doing today
h
I know, we are discussing changing that
w
@happy-kitchen-89482: if both the generator and the generated target are addressable, then you need to be able to render each of them
and yea, as Eric said: in some cases you will see globs.
h
Because otherwise peek is not a good place for depgraph information
h
Today at least Targets replaces the generators with the generated
Right, and I propose in https://github.com/pantsbuild/pants/pull/12952 that we change that to the semantics Stu is proposing. Project introspection shows all addressable targets
h
OK
Always
w
well, to be clear though:
h
?
w
./pants peek $onetarget
should probably show one target…?
h
hm
I dunno
w
basically, if something is addressable, it’s one-in-one-out
h
yeah I agree with that. But 
./pants peek ::
should show everything
h
Interesting, so 
::
implicitly globs over the generated targets
What about 
:
?
w
there is a fidgety thing there. i don’t think we have semantics to say that a 
SingleAddress
doesn’t get expanded, but a glob does.
👍 1
h
imo 
:
should be all targets in that dir, generated or not
w
but… that would be reasonable semantics.
yea.
h
only 
dir:tgt
should be one and exactly one target (for project introspection at least)
w
but… it’s a change.
@happy-kitchen-89482: but, i think that this discussion is probably orthogonal to 
peek
and fields…
unless it’s blocked you from getting a graph from 
./pants dependencies --transitive --closed :: | xargs ./pants peek
…?
at the end of the day, that’s what we need.
h
I still think that is bonkers, but I no longer care...
I am probably wrong
w
i think this discussion has shown that we have more than enough questions to answer in 
peek
, let alone trying to add json and partial field outputs to other goals
Open in Slack
PreviousNext
Powered by