https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0>: new thread for <https://pantsbuild.s...
# development
w
i think that that means that rather than “consumer decides” for 
UnexpandedTargets
vs 
Targets
, it would be a function of the 
Specs
…?
maybe there is still a choice for a literal 
Addresses
list (i.e. https://github.com/pantsbuild/pants/blob/52c0a3be635511a37fda5c10a291e9fd59b2eea9/src/python/pants/engine/internals/graph.py#L95-L98), and 
DependenciesRequest
ow.
actually, i guess this is a function of 
Specs -> Addresses
👍 1
h
It is, but then the issue is 
Addresses -> Targets
w
i think you’re right that we need to fix this soon.
h
How come? Semi related to this topic, I hit a really awkward thing today. In Go, everything has a dependency on its owning go_mod thanks to dependency injection. When building a package, we get all of its direct deps and recursively build. If you use Targets instead of UnexpandedTargets, we replace the target generator with everything generated, which is bad. That's hard to reason about and using UnexpandedTargets means that we break explicit deps on the go_mod We don't need to solve that edge case here, but it speaks to my overall impression that we should figure out the state of targets Soon It also makes me wonder if we really should be valuing a target generator being an alias for generated targets
w
How come?
was realizing that 
./pants peek ::
isn’t going to render the complete graph. it’s the same issue as 
list
, but brought home the impact for me
➕ 1
It also makes me wonder if we really should be valuing a target generator being an alias for generated targets
it needs to be when it is actually named though, right? because it disambiguates?
but yea. there are definitely rough edges here.
h
We definitely need names for target generators sometimes because of disambiguation. But we don't necessarily need to support them acting as an alias! Those are two separate uses of a target generator having an address
w
yea… could just never construct the alias, and always expand it.
even if it was named.
so, basically the macro idea at that point, except with optional names
h
I'll open a ticket about that question of if target generators should be an alias
w
i think they need to be in some cases… e.g. 
resources
and 
files
(which will generally be used via the alias) but i think the question is more whether we ever need to actually render the alias
h
With 
files
and 
resources
, 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 
UnexpandedTargets
vs 
Targets
w
right
but if you can depend on the alias, but it is never actually constructed as a Target and instead just replaced with its expansion, always, that would be another way to get rid of the difference.
a downside of that is that 
./pants list $alias
would not be one in one out, but it would still be net easier to grok.
h
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
w
also that 
Address -> WrappedTarget
wouldn’t work, since the alias might give you more than one =/ … but probably an implementation detail.
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 
Specs
, and only being able to see an alias when it is directly addressed?
h
I don't think any solution can focus on Specs. Specs is only one of many ways that we go from Addressses -> Targets. For example, none of this Go code I've been working on is using Specs and it still has this problem with UnexpandedTargets vs Targets I'm pretty sure the most elegant solution would be getting rid of UnexpandedTargets entirely. Plugin authors no longer have to reason about any of this. I'll open a ticket exploring there when I get home from store
w
Yea, I agree.
h
https://github.com/pantsbuild/pants/issues/13086 cc @happy-kitchen-89482. I have a 4 hour flight tomorrow night, and would love to try to implement this during it
Open in Slack
PreviousNext
Powered by