Prior to 1.17, go.mod was not a complete representation of the dep graph. More broadly, the problem is that programmers expect dependency management tooling to have a lock file, see go.sum, and assume it's a lock file. This isn't a problem with those programmers, it's a problem with Go modules.

> This isn't a problem with those programmers, it's a problem with Go modules.

That seems like a bit of a jump! Maybe there's a better way of building dependency management tooling that doesn't use lock files, it seems strange to tie yourself to this approach just because it's how other tools work.

go.mod is the lock file.

It isn't in the traditional sense. There isn't anything in its specification that guarantees the things that most people expect lock files to guarantee.

Well, I do understand that the actual version used there is ambiguous.

Probably the best would be to take the newest from go.sum. That’s what some scanners are doing now.

Filed bugs with 2 vendors over this though.

The newest from go.sum isn't reliably the version used in the dep graph. The only way to get that information reliably is via go list. Unfortunately.

Oh, you are totally right. I read that in the GitLab issue tracking their version of the problem and totally forgot that’s where they landed.

Also don't forget that more than one version of a dependency might be compiled into your application!

Only one major version. And go considers different major versions to be different dependencies.

not true for go

For the curious it's:

    go list -m all