witty-crayon-2278609/29/2021, 4:43 PM
, it would be a function of the
list (i.e. https://github.com/pantsbuild/pants/blob/52c0a3be635511a37fda5c10a291e9fd59b2eea9/src/python/pants/engine/internals/graph.py#L95-L98), and
Specs -> Addresses
hundreds-father-40409/29/2021, 6:25 PM
Addresses -> Targets
witty-crayon-2278610/02/2021, 4:09 PM
hundreds-father-40410/02/2021, 4:34 PM
witty-crayon-2278610/02/2021, 5:10 PM
How come?was realizing that
isn’t going to render the complete graph. it’s the same issue as
./pants peek ::
, but brought home the impact for me
It also makes me wonder if we really should be valuing a target generator being an alias for generated targetsit needs to be when it is actually named though, right? because it disambiguates?
hundreds-father-40410/02/2021, 5:15 PM
witty-crayon-2278610/02/2021, 5:16 PM
hundreds-father-40410/02/2021, 5:21 PM
witty-crayon-2278610/02/2021, 5:22 PM
(which will generally be used via the alias) but i think the question is more whether we ever need to actually render the alias
hundreds-father-40410/02/2021, 5:24 PM
, that could be solved by having the generator still depend on the generated targets. Then the atom targets will be pulled in transitively This is only to get rid of
witty-crayon-2278610/02/2021, 5:25 PM
would not be one in one out, but it would still be net easier to grok.
./pants list $alias
hundreds-father-40410/02/2021, 5:29 PM
witty-crayon-2278610/02/2021, 5:30 PM
wouldn’t work, since the alias might give you more than one =/ … but probably an implementation detail.
Address -> WrappedTarget
There’s a ton of value to looking at the target generator imo though, like ./pants peek on a go_mod target. NB that it generates targets with a different shape than itself@hundreds-father-404: then maybe it really is about the
, and only being able to see an alias when it is directly addressed?
hundreds-father-40410/02/2021, 5:39 PM
witty-crayon-2278610/02/2021, 5:43 PM
hundreds-father-40410/02/2021, 7:26 PM