Move from label collection to label stamping
ittaiz opened this issue · 7 comments
Currently we collect labels in various places (scala_library/scala_binary/scala_import/etc) and propagate them onwards.
This is valuable since when we want to report to the user on a problem with a transitive dependency (unused deps/strict deps) we have a meaningful label and not just a file path.
Java rules also used a similar (but different) approach but have moved a year or more ago to a different approach.
Their current approach "stamps" the jar upon creation* with its label (k/v in the manifest.mf) and so if they ever need to report (which is the rare case) then and only then they pay the (higher) price of opening the jar and reading the manifest to improve the user reporting.
This doesn't actually happen on jar creation but implicitly on ijar creation.
This means that we need to explicitly stamp our outputs for scala_import and scala_macro_library since they don't go through ijar. java_common has a special API for this.
Note that some tests will fail with this change since our existing mechanism allows us to remap labels (if bar exports foo then when someone uses bar the outputs of foo will be listed as bar). This is valuable in having facade targets for logical libraries.
After lengthy discussions it was agreed that the solution for this pattern should be in a smarter tool that will use bazel query to find the fact that bar exports foo and will add bar to the caller.
Also the changes in #716 are needed.
@long-stripe wdyt about taking this one? Shouldn't be very complicated and will be a nice win (remove a lot of noise from our code)
@ittaiz Yeah if you think it's a good thing to start on! I can't promise anything timeline wise, but I will try and carve out some personal time in the coming week or so to look at this.
FYI small heartbeat - I am still interested in tackling this, but haven't had time lately.
@ittaiz I was just gonna meander about and deep dive in when I have the time, but if you have links to relevant parts of the codebase that I should be focusing on, that would be super helpful!
Unfortunately it’s spread throughout the codebase. I’d start in the lead (compiler plugin) and trace back.