Interdependency with ginkgo pollutes go.sum of downstream projects

onsi / gomega

Ginkgo's Preferred Matcher Library

http://onsi.github.io/gomega/

MIT License

2.18k stars 284 forks source link

Interdependency with ginkgo pollutes go.sum of downstream projects #390

Open dolmen opened 4 years ago

dolmen commented 4 years ago

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 commented 4 years ago

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

blgm commented 4 years ago

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 commented 4 years ago

....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 commented 4 years ago

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 commented 4 years ago

@myitcv any ideas?

onsi commented 4 years ago

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 commented 4 years ago

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

This issue will be fixed by https://github.com/golang/go/issues/36460. Having cyclic module dependencies should not be an issue, and https://github.com/golang/go/issues/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 https://github.com/golang/go/issues/36369 and friends which are all (in)directly related to the problem you describe.

blgm commented 4 years ago

Thanks @myitcv! That’s really helpful.