go.mod/MODULE.bazel update from indirect to direct marks other go_* targets as changed

[darkrift]

When updating go.mod to switch a dependency from indirect to direct and add it to MODULE.bazel, other go targets are marked as changed.

Reproducer : https://github.com/darkrift/determinator_go_mod_rebuild_all

$ ~/Downloads/target-determinator.darwin.arm64 046e13d2d93d1c7caae217461a0c86c428da7a50
2025/03/06 10:47:45 Processing revision 'before' (sha: 046e13d2d93d1c7caae217461a0c86c428da7a50)
2025/03/06 10:47:46 Running cquery on deps(//...)
2025/03/06 10:47:50 Running cquery on //...
2025/03/06 10:47:51 Finding compatible targets under //...
2025/03/06 10:47:52 Matching labels to configurations
2025/03/06 10:47:53 Hashing targets
2025/03/06 10:48:04 Processing revision 'after' (current working directory state)
2025/03/06 10:48:06 Running cquery on deps(//...)
2025/03/06 10:48:11 Running cquery on //...
2025/03/06 10:48:12 Finding compatible targets under //...
2025/03/06 10:48:13 Matching labels to configurations
2025/03/06 10:48:13 Hashing targets
//services/a
//services/a:a_lib
//services/b
//services/b:b_lib
2025/03/06 10:48:15 Finished after 32.877560584s

I don't think the issue is with target-determinator, but opening it here for the investigation and figure out where to open the real issue.

[darkrift]

Running with -verbose :

//services/a Changes: RuleInputChanged[//services/a:a_lib[096dcc84165363e69a851ebe8131b032f5448c94ddc4951775429dc78e79f898]]
//services/a:a_lib Changes: RuleInputChanged[@com_github_samber_lo//:lo[096dcc84165363e69a851ebe8131b032f5448c94ddc4951775429dc78e79f898]]
//services/b Changes: NewLabel
//services/b:b_lib Changes: NewLabel

[darkrift]

Running bazel cquery --output textproto @com_github_samber_lo//:lo before and after does show what's different :

$ diff before.txt after.txt 
102,103c102,103
<         string_list_value: "@@gazelle++go_deps+org_golang_x_text//cases:cases"
<         string_list_value: "@@gazelle++go_deps+org_golang_x_text//language:language"
---
>         string_list_value: "@org_golang_x_text//cases:cases"
>         string_list_value: "@org_golang_x_text//language:language"
304,305c304,305
<       rule_input: "@@gazelle++go_deps+org_golang_x_text//cases:cases"
<       rule_input: "@@gazelle++go_deps+org_golang_x_text//language:language"
---
>       rule_input: "@org_golang_x_text//cases:cases"
>       rule_input: "@org_golang_x_text//language:language"

[darkrift]

I suppose if a dependency also changes location where it gets renamed in the current repo, that will also make it think that it has changed. even though the configuration and the graph is logically the same.

Maybe we should have some sort of "alias mapping patterns" where we could define that @@gazelle++go_deps+org_golang_x_text is logically equivalent to @org_golang_x_text using some regex replacement patterns ^@@gazelle\+\+go_deps\+(.+)$ => $1.

[darkrift]

@illicitonion would it be the time where target-determinator start looking at $internal_attr_hash ?

What's the rationale behind having the rule input label name as part of the hash ? The hash of the target in itself should be sufficient, is it not ?

[illicitonion]

Thanks for digging into this!

On the alias mappings - yeah, I think it would be great to be able to map apparent repo names to canonical ones - as we run all our queries from the root repo, this feels tractable. I'm not sure what APIs bazel exposes that may allow us to construct this mapping - effectively we'd want to uphold the constraint that all labels always start with @@. We already canonicalise @// to // so pulling in an extra piece of query information to turn @org_golang_x_text// into @@gazelle++go_deps+org_golang_x_text// feels super reasonable, as long as we only perform the query once.

On including names - it's important to include both names and packages. We're only performing cquery here, and the output of that ends up being the input to analysis (i.e. constructing actions from configured targets). Analysis gets access to label information, and frequently uses it (typically, for example, a rule will use the name of the target to decide on output file names). These are significant differences - renaming an output file is a meaningful impact on a rule. We could try to be more precise by diffing the output of aquery rather than cquery, but that would require us letting Bazel do even more execution (slowing things down), and would require us to process quite a lot more information (targets typically generate multiple actions, and often many of those actions are irrelevant for actual builds). Not ruling this out - aquery diffing would be interesting and precise, but it would make things even slower to achieve that precision.

[darkrift]

The slowness impact could be reduced with #3

[darkrift]

It seems like bazel mod dump_repo_mapping "" would do what we want here :

$ bazel mod dump_repo_mapping "" | jq -S
{
...
  "org_golang_x_text": "gazelle++go_deps+org_golang_x_text",
...
}
$

[sitaktif]

Let's keep this issue open even after #108 is merged: we want to add an integration test case based on the reproducer above, once we figure out #104.