Circular dependency with testify
kaovilai opened this issue ยท 11 comments
objx requires github.com/stretchr/testify v1.7.1
github.com/stretchr/testify requires objx v0.4.0
Would be cool if it could be avoided. No other reason in particular.
Can you elaborate on why this needs fixing? Did you run into any issues?
Just a go.sum eyesore that's all.
For some reason golang don't prevent module circular dependency but does at the package level.
It also makes snyk complain about security issues (these issues should be gone from testify 1.8.0):
SNYK-GOLANG-GOPKGINYAMLV3-2841557, SNYK-GOLANG-GOPKGINYAMLV3-2952714
facing the same problem of @gildas on a Snyk pipeline.
But checking out the code, I noticed that the problem was already fixed on master branch, maybe what is missing is generate a new package release.
created a new release
thank you so much @geseq.
just a question, the old version of objx still be used by testify 1.8.0, and by that, indirectly, is using a vulnerable version of the yaml.v3
package, as the dependency tree below:
- testify v1.8.0
- objx v0.4.0
- testify v1.7.1
- yaml.v3 v3.0.0
Vulnerability found here:
https://security.snyk.io/package/golang/github.com%2Fgo-yaml%2Fyaml
Is threre any schedule for dependabot to run and update it?
Sorry I have no idea. Youโd have to ask this in the testify repo
I created this issue in the testify repo: stretchr/testify#1292.
We might need to add a new tag for objx (maybe v0.5.1), so as to stop the backwards pointing to older, vulnerable versions.
Currently here in objx, the bump to testify 1.8.1 is after the v0.5.0 tag:
> git log --oneline -3
c0315e5 (HEAD -> master, origin/master, origin/HEAD) Fix a couple typos in the README.md (#128)
40ef69b Bump github.com/stretchr/testify from 1.8.0 to 1.8.1 (#126)
50a2c06 (tag: v0.5.0) Fix typo in Taskfile (#122)
I was able to solve this by adding this to my go.mod
file:
exclude github.com/stretchr/testify v1.7.1
To the maintainer: would you accept a PR that would drop the use of testify
and just use testing
? This would fix that dependency circle forever. I'm ready to do the work.
I found an easier way to help Go break the cycle. See #140. Thanks to @westy92 and @mgibson-r7.