deps: fix dependency cycle with objx (again)

[dolmen]

Summary

Update go.mod to break dependency cycle with github.com/stretchr/objx v0.5.2 which depends on testify v1.9.0.

Changes

$ go mod edit -dropexclude=github.com/stretchr/[email protected] -exclude=github.com/stretchr/[email protected]
$ go mod tidy

Motivation

Dependency pollution in downstream projects

Related issues

• deps: fix dependency cycle with testify (#124) objx#140

[brackendawson]

Can you put a comment after line 10 to explain how to check this is correctly set for the next time dependabot updates objx?

[dolmen]

It is not yet clear to me if we will have to continuously upgrade the exclude line.

It is quite unfortunate that objx has been upgraded to v0.5.2 just before the testify v1.9.0 release. I had done the minimalist change needed in objx v0.5.1 but v0.5.2 destroyed that with a Go version bump in go.mod.

[brackendawson]

What is the purpose of this change?

If it is to minimise the size of the module graph; then the exclude should always be set to the version of testify which the version of objx we use imports.

[dolmen]

The purpose of this line is to cut the circular graph of dependencies of objx and testify, and tell go mod to not bother injecting older versions of testify in go.sum, and tell go mod applied on downstream projects to not bother with older versions of testify.

testify -> objx v0.5.2 -> testify v1.8.2 -> objx v0.5.0 -> testify v1.8.0 -> objx v0.4.0 -> testify v1.7.1 -> objx v0.1.0
(also each version of testify and objx brings its own versions of other dependencies)

[brackendawson]

How about?

require (
	github.com/davecgh/go-spew v1.1.1
	github.com/pmezard/go-difflib v1.0.0
	github.com/stretchr/objx v0.5.2 // to avoid a cycle the verision of testify used by objx should be excluded
	gopkg.in/yaml.v3 v3.0.1
)

[dolmen]

@brackendawson I don't understand what you suggest.

[brackendawson]

I am suggesting to add the above comment to line 10 of the go.mod file.

This change was missed because the person that merged the dependabot PR didn't know there was an additional requirement. The next person to review a dependabot PR may not be you or I. If there is a comment on the line then the reviewer is likely to notice?