#development
Title
w
witty-crayon-22786
09/29/2021, 4:43 PM@hundreds-father-404: new thread for https://pantsbuild.slack.com/archives/C0D7TNJHL/p1632933458477400?thread_ts=1632931275.469400&cid=C0D7TNJHL
i think that that means that rather than “consumer decides” for
UnexpandedTargetsTargetsSpecsmaybe there is still a choice for a literal
AddressesDependenciesRequestow.
actually, i guess this is a function of
Specs -> Addresses👍 1
h
hundreds-father-404
09/29/2021, 6:25 PMIt is, but then the issue is
Addresses -> Targetsw
witty-crayon-22786
10/02/2021, 4:09 PMi think you’re right that we need to fix this soon.
h
hundreds-father-404
10/02/2021, 4:34 PMHow 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
witty-crayon-22786
10/02/2021, 5:10 PMHow come?was realizing that
./pants peek ::list➕ 1
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?
but yea. there are definitely rough edges here.
h
hundreds-father-404
10/02/2021, 5:15 PMWe 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
witty-crayon-22786
10/02/2021, 5:16 PMyea… 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
hundreds-father-404
10/02/2021, 5:21 PMI'll open a ticket about that question of if target generators should be an alias
w
witty-crayon-22786
10/02/2021, 5:22 PMi think they need to be in some cases… e.g.
resourcesfilesh
hundreds-father-404
10/02/2021, 5:24 PMWith
filesresourcesUnexpandedTargetsTargetsw
witty-crayon-22786
10/02/2021, 5:25 PMright
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 $aliash
hundreds-father-404
10/02/2021, 5:29 PMThere'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
witty-crayon-22786
10/02/2021, 5:30 PMalso that
Address -> WrappedTargetThere’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
Specsh
hundreds-father-404
10/02/2021, 5:39 PMI 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
witty-crayon-22786
10/02/2021, 5:43 PMYea, I agree.
h
hundreds-father-404
10/02/2021, 7:26 PMhttps://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