Q: May it be that the authzed-go spicedb client ad...
# spicedb
d
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 )
so without going further and check using godegraph i thought why not ask here first 😉
it may also be https://github.com/authzed/grpcutil/blob/main/test.go which adds it. cc @jzelinskie that test.go and its dependencies are included in a normal build as it is not using the _test pattern, is that on purpose? if not, i think a rename to _test.go or whatever may help 😉
have a nice weekend, I'll be off for today. Would be great to get an answer, and happy to help 🙂 just not sure why it is there in the first place. It is callable when you include grpcutil, but it needs a testing.T param, so definitely nothing for production use. I'd remove it as it loads a pretty big dependency and thus creates unnecessary maintenance burden and attack surface, but I don't have all the pieces. Use case is not clear to me 🙂
j
👋 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).
d
👋 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.