https://pantsbuild.org/ logo
Join Slack
Powered by
I wrote up some thoughts on “labeled dependencies”...
# development
f
I wrote up some thoughts on “labeled dependencies” as a way to support classpath scopes for JVM dependencies (among other possible uses). Comments welcome and encouraged! https://docs.google.com/document/d/1r9nCf62lHeaz5NGldhsZwu19_SzRuTCrPEELgn_9l2g/edit?usp=sharing
💯 1
c
I like it 🙂 Few thoughts from the OQ’s section: I like things that are typed down. If the DependencyEdge is a union type, the conversion from two Addresses (source and target) to a DependencyEdge could be extended dynamically by plugins. So we could then introduce a dependency edge with a 
scope: str | None
now, and still leave the door open for extensions without the need for dedicated PRs for each such change. (Perhaps those edges would preferably be grouped by address, as there could be any number of edges, per address then)
I also like the suggested BUILD file syntax for labels. Only concern is that any macro, if they come to be, need to mix well with other labels, so that also 
scoped("//src/jvm/org/pantsbuild:foo!custom=label", "provided")
works.
I think it is better to defer the calculation of the dependency edges, rather than storing them in the dependencies field (as there to my knowledge isn’t any clean way to invoke rules during field initialization)
w
i’m not sure that edge centric is going to be the way to go… so while the implementation seems fine (more typesafe would be good though? that was the idea behind `Dependencies` field subclasses), the big thing to figure out from my perspective is node vs edge (see)
but maybe “edge vs node” is moot, and it should all be edge, but with default-inbound-edge-labels per node? unclear.
(which was one of @curved-television-6568’s suggestions on the ticket)
f
w
what is an 
xtest
dep?
since go doesn’t support scoping, it’s not clear why anything would need to be scoped for go though: https://github.com/golang/go/issues/26913
f
xtest
deps are imports from the package’s “external tests” (i.e., 
*_test.go
files put into a package suffixed with 
_test
). external tests are compiled as a separate virtual package from the regular sources for the package.
the regular package should not be linked with 
xtest
deps.
w
got it. yea, that makes sense as a consumer-decides case. but you could maybe also argue that rather than being a scoped dep of one target, there are actually two consuming targets there
k, thanks. didn’t mean to move discussion here… just wasn’t finding references to 
xtest
Open in Slack
PreviousNext
Powered by