https://pantsbuild.org/ logo
#development
Title
# development
f

fast-nail-55400

11/28/2021, 11:46 PM
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

curved-television-6568

11/29/2021, 6:20 AM
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

witty-crayon-22786

11/29/2021, 10:33 PM
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

fast-nail-55400

11/29/2021, 11:45 PM
w

witty-crayon-22786

11/29/2021, 11:48 PM
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

fast-nail-55400

11/29/2021, 11:55 PM
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

witty-crayon-22786

11/29/2021, 11:58 PM
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