Cyclical Indirect Dependencies & Go.work can cause divergence

[stefanpenner]

Note: There is a known limitation associated with PR #1731. After discussion, we've decided to proceed with that PR despite the limitation. This issue will serve as a placeholder for future exploration and work to address the limitation.

Also Note: it is strongly recommended, even once support is added, to avoid these Dependency Cycles, especially when they cross workspace boundaries. Debugging and resolving headaches due to such cycles is the leading cause of early aging in software developers...

What version of gazelle are you using?

908ba74

What version of rules_go are you using?

N/A

What version of Bazel are you using?

7.1.x

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

N/A

What did you do?

Given Go Modules A, B, C, where:

• A and B are in the go.work
• C is not part of the go.work
• C depends on A
• B depends on C

What did you expect to see?

C's dependency on A should be that of A in specified in the go.work.

What did you see instead?

C's dependency on A is the version specified in C's go.mod, rather then A in the workspace.

[stefanpenner]

After exploring potential solutions, I believe it might be beneficial to expand Gazelle's capabilities to allow it to resolve a package within an indirect dependency, not as an external go.mod but as a target within the root workspace.

Then at the time go_repository invokes gazelle in external go.mod's we pass in the appropriate resolution parameters to ensure the right targets are used.

Although gazelle today does support resolution overrides, they today require exhaustive target lists, which if used as-is would greatly complicate the implementation. Alternatively, if we could instead merely adjust the resolution repo target root, we could keep this simple.

For instance, currently, the naming convention algorithm transforms a module identifier like my.go.mod.com/foo into com_mod_go_my_foo. However, by implementing a mapping override feature, we could directly link my.go.mod.com/foo to the corresponding go.mod label in our workspace.