https://pantsbuild.org/ logo
Join Slack
Powered by
<@U053HNE90>: regarding zinc
# development
w
@bored-art-40741: regarding zinc
although file-level dependency inference doesn’t get you everything that 
zinc
would, my hope is that the last 20% is not strictly necessary
i’m probably telling you what you already know, but: 
zinc
primarily does two things: 1. track file->symbol level dependencies 2. know which APIs are public
since the finest granularity that zinc can compile at is “a file”, file-level dependency inference gets you about 80% of that
the bit that it doesn’t get you is “public symbol” level awareness, and knowing whether a used symbol has changed
while that’s nice to have, i’m not sure how critical it is in practice. and you can get 10% of that remaining 20% by having downstream compiles depend on an “ijar” rather than on the entire classpath
bazel’s rules still use zinc, but my guess is that it is as more to avoid the 80% (needing explicit file-level targets) than for the symbol-level awareness
b
I was actually originally going to use scalac, then I waffled and decided I'd might as well start with zinc but ignore all of the analysis. I really have no preference, I can stick with pure scalac if you think that's better
w
yea, i think it is.
the other thing is that scala 2 at least supports 
-Youtline
, which emits a file of signature pickles
having trouble googling for it because of lame search syntax… sigh. but this is decent: https://github.com/scala/scala-dev/issues/643
the signature pickles are effectively an 
ijar
, emitted as a sideeffect of compilation
which gives you that last 10% i was mentioning
b
Ahh nice, and that will also substantially improve cache reconvergence when you have to recompile but the emitted interfaces don't actually change, hence your dependees don't need to recompile at all
w
yea, exactly.
at that point, the last thing that zinc (hypothetically) could do for you is identify that “well, yea: the public members changed, but not any of the ones that this file depends on”… and that’s pretty micro.
(mm… it doesn’t look like scala 3 supports `-Youtline`… i suspect that it will have a different file format)
b
Off the top of your head, do you know if we still need the full transitive classpath for Scala compilation? This used to be the case due to path dependent types, and I assume that hasn't changed
w
the challenge was always that error messages sucked when a dependent type wasn’t present. precisely when you need them was never obvious.
it could be solved manually by having a producing library “export” some of its own deps, such that the “direct dependencies” of a consumer expanded a bit.
b
Hm
w
(i.e., when you depend on W, you also depend on X, Y, Z)
@bored-art-40741: realistically, i think that it has to be a toggle for now.
b
Yeah that makes sense. I'll start with full transitive to keep it simple, and we can add the direct-dep-only mode in a followup
w
and perhaps in the future we can fiddle with detecting whether we need more at compile time
sure
…it occurs to me that “including more of the transitive deps but not all of them” is something that you can do immediately before compilation, after your transitive deps have compiled. which is kind of interesting.
b
Yeah, I wonder if in principle you have the information available that you need at that point
w
yea, i’m certain that you do. my guess is that it’s a question of how finicky it is to nail down the requirements.
ime, it will be stuff shaped like “inherits a member from a super trait”
anywho. that bit would be very science experimenty.
b
I also wonder if 
ijars
(or their Scala moral equivalents) solve all of the practical problems so thoroughly that it's not worth attempting to restrict to direct deps
w
potentially, yea. that feels like another 80/20.
b
If it's not an assumption that the language gives you, even with some restrictions or caveats, attempting to get around that is always going to be fraught with peril, and maybe not have the tangible benefits that it used to have with Zinc and the old stack
Honestly I'm not even sure how valuable it is for Java. There I think it's more a correctness thing, whereas with Scala it was always trying to eek out as much as we could from Zinc performance
w
for large classpaths, it can be 1/10 of the data or less to depend on only direct deps
whether that matters is an open question, but it might for remoting.
Open in Slack
PreviousNext
Powered by