Interdependency with ginkgo pollutes go.sum of downstream projects

[dolmen]

On a project which uses go-redis which uses ginkgo v1.13.0 in its testsuite:

$ go mod graph | grep -E 'gomega.*ginkgo|ginkgo.*gomega'
github.com/onsi/ginkgo@v1.13.0 github.com/onsi/gomega@v1.10.1
github.com/onsi/gomega@v1.10.1 github.com/onsi/ginkgo@v1.12.1
github.com/onsi/ginkgo@v1.12.1 github.com/onsi/gomega@v1.7.1
github.com/onsi/gomega@v1.7.1 github.com/onsi/ginkgo@v1.6.0

Each version of ginkgo depends on an older version of gomega which brings an older version of ginkgo which...
Each old ginkgo or gomega version brings obsolete references in go.sum which are not relevant for the build.

Please make make a serie of synchronised release of both gomega and ginkgo where all their external dependencies are at the same versions to break the chain.

[onsi]

🤮 thanks for calling this out. Will try to fix it with the next releases.

[blgm]

I agree this is ugly. It could be very hard (or impossible) to synchronously release Ginkgo and Gomega because we would have to know the checksums in advance to put into go.sum. For instance to release Ginkgo version M we need to know the checksum of Gomega version N, which in turn depends on the checksum of Ginkgo version M.

[onsi]

....indeed. Anyone know of an idiomatic way to resolve this? Can we specific a floating server so that, e.g. Gomega imports ginkgo@>1.12.0 and Ginkgo imports gomega@>1.10.0 and allow go to use whatever sufficiently compatible versions it finds? Not sure if that solves the go.sum issue, though, since there's an explicitly computed checksum?

[blgm]

We do that. The go.mod file specifies minimum versions and the go.sum has checksums of versions that were actually used.

Some unpalatable options that I’ve thought of so far are:

• merge the repos
• don’t check in go.sum (the Go modules docs say you should check it in)
• break the two-way dependency by moving some core functionality into “Q” such that both Gomega and Ginkgo depend on Q, and not on each other
• raise an issue with Go modules and ask for advice (the advice may well be to avoid interdependent modules)

[blgm]

@myitcv any ideas?

[onsi]

That list seems pretty comprehensive, thanks @blgm

Ironically the two are actually quite decoupled - the coupling only enters in because they leverage each other in their respective test suites.

[myitcv]

Sorry for the slow reply, I've been off-radar for the last ~week.

This issue will be fixed by golang/go#36460. Having cyclic module dependencies should not be an issue, and golang/go#36460 will ensure that is the case.

In particular, if you look through the design doc linked from that issue (https://go.googlesource.com/proposal/+/master/design/36460-lazy-module-loading.md) you will note golang/go#36369 and friends which are all (in)directly related to the problem you describe.

[blgm]

Thanks @myitcv! That’s really helpful.