Q: May it be that the authzed-go spicedb client adds a testify dependency? If so, why? Context: We just added a "test setup" class that is shared in a few packages (creating a dockertest container with spicedb). As this would add an unneeded dockertest dependency to the binary we build, I looked a bit on how to avoid this, and stumbled over https://www.dolthub.com/blog/2022-11-07-pruning-test-dependencies-from-golang-binaries/ - fwiw, adding a build constraint

//go:build !release

to that file and changing our build to run using

-tags release

did the trick (see also: https://github.com/golang/go/issues/12120#issuecomment-163836886 ). Then out of curiosity, I also checked for testify using

strings <my-binary> | grep testify

, and it is also included in our binary. Then I checked our code if sth imports testify, our code did not (out of

_test

, which doesn't include it in the binary). So I asked myself why and could locate it in the files using or initializing the authzed client (to be fair, 99% locate it using

go list -json | jq .Deps | grep testify

inspired by that article on package level, testify is only shown inside the

Deps

in the package where we use /init the client )

👋 This is a common function that we use in multiple projects for implementing tests, so we've refactored out into grpcutil so it can be imported as a library. I think all of our projects eventually pull in testify, so we hadn't really noticed any issue yet. Is it critical that you don't include testify at all in your build? We could probably create another package in grpcutil and import from there to avoid it (what that GitHub issue you linked recommends).

👋 thanks for the answer! No, not at all critical, more an unexpected find, and removing/outsourcing it would be "good practice" w.r.t. supply chain security I'd say, to have the least dependencies possible 🙂 I'd appreciate it.