Unnecessary Ginkgo dependency in go mod

[unmarshall]

Gomega can be used with or without Ginkgo. Using BDD styled testing frameworks is a personal choice and i for one find it quite difficult to read test cases that are written in Ginkgo. I just prefer using standard golang native test framework along with a minimalist assertion library.

I was hoping to use gomega as it works also with go native tests but unfortunately i do not wish to pull in ginkgo as a dependency which i am forced to do as soon as i include gomega. I was really hoping that you would consider making the core assertion library as a separate go module which will be independent of ginkgo and then provide extensions for easy consumption in ginkgo.

[onsi]

hey there - i’ve honestly tried real hard to make sure gomega doesn’t have a direct dependency on ginkgo and… as far as I know. it doesn’t! just a test dependency which i would have expected to come up as an indirect dependency. i’m honestly unsure why go mod thinks ginkgo is a required direct dependency. it really shouldn’t be (and really isn’t!)

[pohly]

I and @onsi discussed this a bit more after this issue was created.

The problem is that Go has no concept of a "test-only" dependency: even if Gomega only uses Ginkgo for testing, downstream consumers of Gomega will see Ginkgo show up as an indirect dependency of their project, with little to no support in dependency analysis tools to indicate that the Ginkgo dependency is "less important".

@onsi suggested a possible way to avoid this:

• A "dev" branch has all the tests. This is where all development happens, including testing.
• The "master" branch merges that "dev" branch for each release and then all tests get deleted on it.
• Releases get tagged for downstream consumers on that stripped "master" branch -> no Ginkgo dependency.

[thediveo]

I remember having seen the issues of test dependencies appearing from time to time on the Go issue tracker, and mostly unrelated to Ginkgo. The stance of the Go project IIRC here is that this is by design.

From my own experience my go.mod collects a lot of other test frameworks as indirect test dependencies anyway, so trying to fight this project by project...

[pohly]

It's indeed by design because then downstream consumers can do go test <upstream component> in their downstream project with a potentially different set of other shared dependencies. This can give the downstream consumer some higher confidence that the upstream component still works.

I know of this being done, albeit with more important upstreams and not with Gomega.

The problem with the Go design is that downstreams cannot opt out of this feature. This would be ideal: "ignore Gomega's test dependencies" and then not have Ginkgo show up. But apparently this is not seen as a big enough problem to do more about it.

The problem with #816 (comment) is that downstreams cannot run Gomega tests anymore because Gomega doesn't provide them anymore. I don't think this is a problem in practice. Someone who absolutely wants to do it could update Gomega in their project to a commit on the "dev" branch.