GRPC depends on GRPC?

[Benjamintf1]

Howdy! We were looking into why some of our code seems to include older version of grpc, and it turns out that they're coming from inside the grpc package. This pr https://github.com/grpc/grpc-go/pull/3083/files seems to have pulled in grpc in go.sum....question...why? Isn't it a bit sketch for grpc to have go.sum that refers to older versions of grpc?

[easwars]

@menghanl :

The go.sum from master has three versions of grpc:

google.golang.org/grpc v1.19.0/go.mod h1:mqu4LbDTu4XGKhr4mRzUsmM4RtVoemTSY81AxZiDr8c=
google.golang.org/grpc v1.23.0/go.mod h1:Y5yQAOtifL1yxbo5wqy6BxZv8vAUGQwXBOALyacEbxg=
google.golang.org/grpc v1.25.1/go.mod h1:c3i+UQWmh7LiEpx4sFZnkU36qjEYZ0imhYfXVyQciAY=

Is it because of transitive dependencies? gRPC-Go depends on something which has a dependency on older versions of gRPC-Go?

[menghanl]

Yes, could be due to transitive dependicies.

go.sum has many duplicate entries. It probably all comes down to golang/go#33008

We don't manually edit go.sum. We just run go mod tidy.
And go.sum doesn't cause any overhead. It's only for go mod to verify the checksum when needed.

[Benjamintf1]

I think it could from dependencies not calling go mod tidy on go.sum? It seems strange to have a circular dependency on grpc though? It's just concerning to see extra entries in go.sum when trying to determine what is being compiled into a binary.

[menghanl]

Technically, those are grpc with different versions, so the dependency is not circular :)

If I remember correctly, a module appearing in go.mod/go.sum doesn't necessarily mean it will be compiled into the final binary. Those are dependencies of the module, but during compiling, only necessary packages are pulled in.
It could still mean that you will need to download the unnecessary modules and never use them, but I'm not too concerned about that.

And in the end, this is a question about the go module package management. There's not much we can do here.