5

Here's a snippet from a go.sum file for a project I maintain.

github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
github.com/golang/protobuf v1.3.5 h1:F768QJ1E9tib+q5Sc8MkdJi1RxLTbRcTf8LJV56aRls=
github.com/golang/protobuf v1.3.5/go.mod h1:6O5/vntMXwX2lRkT1hjjk0nAC1IDOTvTlVgjlRvqsdk=

As far as I can tell, this project, and the other projects it depends on, only use v1.3.5.

Is there a way to determine why v1.3.1 and v1.2.0 are in the go.sum file? For example, can I run go mod why ... with something in the place of ... to determine why those lines are present?

I understand they are not being used by the project when I invoke import "github.com/golang/protobuf", but I would like to understand the toolchain a little better.

Kevin Burke
  • 61,194
  • 76
  • 188
  • 305

2 Answers2

3

If you use go mod graph, you can see the full dependency list, including the versions your project is not using. Some sample lines from the go mod graph output.

github.com/acme/project github.com/getsentry/sentry-go@v0.5.2-0.20200226112222-4dddaaad5cc5
...
github.com/getsentry/sentry-go@v0.5.2-0.20200226112222-4dddaaad5cc5 github.com/onsi/gomega@v1.7.1
...
github.com/onsi/gomega@v1.7.1 github.com/golang/protobuf@v1.2.0
Kevin Burke
  • 61,194
  • 76
  • 188
  • 305
  • There might be multiple (unused versions) if go mod tidy wasn't done and these are not listed by go mod graph. – Volker Mar 28 '20 at 07:32
2

I believe, this happens due to cyclic interdependency that protobuf has.

The issue has been addressed here already: https://github.com/golang/protobuf/issues/1204

However, they are not going to do anything about it, cause it is not a technical problem, the projects can be built.

Maria Efimenko
  • 148
  • 8