为什么我使用 golang 模块，并导入一个没有选择模块的模块，但是 go.sum 文件有 go.mod 文件哈希？

Question

I am now using golang 1.13 and use go module.

However, when I import a package (for example, a) that is not opted in go module, in go.sum file there is still two lines. Go module tells us that "Each known module version results in two lines in the go.sum file. The first line gives the hash of the module version's file tree. The second line appends "/go.mod" to the version and gives the hash of only the module version's (possibly synthesized) go.mod file. The go.mod-only hash allows downloading and authenticating a module version's go.mod file, which is needed to compute the dependency graph, without also downloading all the module's source code."

( https://tip.golang.org/cmd/go/#hdr-Module_downloading_and_verification ).

But this package is not a module, and so it does not have a go.mod file? For example, if I import package call "github.com/example/a" that is not a module, in go.sum file, it still has these two lines:

github.com/example/a v0.0.0-20190627063042-31896c4e4162 h1:rSqi2vQEpS+GAFKrLvmxzWW3OGlLI4hANnEf/ib/ofo=

github.com/example/a v0.0.0-20190627063042-31896c4e4162/go.mod h1:tcpxll8wcruwpPpWBbjAsWc1JbLHld/v9F+3rgLIr4c=

My question is, how the second line generated?

Answer 1

go.sum contains the expected cryptographic checksums of the content of specific module versions. Each time a dependency is used, its checksum is added to go.sum if missing or else required to match the existing entry in go.sum.

Every package/module is dependency and every dependency mean to be maintained with checksums in go.sum so whether it is package or module it would be maintained.

The sources would be downloaded in $GOPATH/src directory accordingly.

TRY -

Answer 2

Cause in into the go.sum file are written EVERY dependencies sum hash. The one related to your go.mod file, and the one imported from the modules that you have imported. Try run go mod tidy in order to reduce the imported modules, your go.mod file will contains some //indirect import, that are the one that your imported modules use internally.

Answer 3

Maybe the Golang source code can explain the reason:

func (r *codeRepo) legacyGoMod(rev, dir string) []byte {
    // We used to try to build a go.mod reflecting pre-existing
    // package management metadata files, but the conversion
    // was inherently imperfect (because those files don't have
    // exactly the same semantics as go.mod) and, when done
    // for dependencies in the middle of a build, impossible to
    // correct. So we stopped.
    // Return a fake go.mod that simply declares the module path.
    return []byte(fmt.Sprintf("module %s\n", modfile.AutoQuote(r.modPath)))
}

code from here: https://github.com/golang/go/blob/acac535c3ca571beeb168c953d6d672f61387ef1/src/cmd/go/internal/modfetch/coderepo.go#L857

↓ VSCode open /usr/local/go/src :

1. locate to cmd/go/internal/modfetch/coderepo.go , add a breakpoint to func legacyGoMod
2. locate to cmd/go/internal/modfetch/coderepo_test.go , press F5
3. wait for a while, stop at the breakpoint