Also #27633

@juliehockett Thanks for the detailed example! I agree that this sounds like a duplicate of #27633.

There are some more details here https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-indirect-and-test-dependencies-in-my-gomod and https://tip.golang.org/cmd/go/#hdr-Maintaining_module_requirements.

I'll close this bug in favor of discussing on #27633.

Thanks for the response! I'm actually thinking this might be subtly different, because we've also run into this as because go mod download is insufficient to build with go build -mod=readonly. The go build command generates the same go.sum file as the go mod tidy command above, and so it errors out under the readonly flag because this difference is persistent there. Is that intended behavior?

Our solution thus far has been to run go mod download && go mod tidy and then do the readonly build, but that's not ideal from a build aesthetic point of view.

(I'm commenting on this bug because the duplicate liked looks like it's talking about differences in the go mod tidy and go build output, not the differences in go mod download and go build, but I could just have an incomplete picture)

Thanks, I'll re-open. Let's cc @bcmills and @jayconrod who own cmd/go who can help clarify this behavior.

This is likely related to #29772.

That said, it would be helpful to have an exact reproducer for this: the go.mod file alone is not sufficient, because go mod tidy follows import statements from all of the .go source files in the main module.

@juliehockett, could you provide the .go source files for this example?

You bet -- main.go (a simple HTTP test) is:

package main

import (
	"fmt"
	"net/http"
	"os"

	"rsc.io/quote"
)

func handler(w http.ResponseWriter, r *http.Request) {
	if quote.Hello() == "Hello, world." {
		fmt.Fprintf(w, "PASS")
	} else {
		fmt.Fprintln(w, "FAIL")
	}
}

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":"+os.Getenv("PORT"), nil)
}

Oh, I get it now.

go mod download is downloading all of the modules in the dependency graph, which it can determine from reading only the go.mod files. It doesn't know which of those modules are actually needed to satisfy a build, so it doesn't pull in the checksums for those modules (because they may not be relevant).

On the other hand, go mod tidy has to walk the package graph in order to ensure that all imports are satisfied. So it knows, for a fact, without doing any extra work, that the modules it walks through are needed for a go build in some configuration.

So this is a bit confusing (and we should think about that some more when other issues are reported), but the behavior originally reported seems correct, at least in the sense that everything is working as designed and neither command is doing any work beyond what it was asked to do.

For your use case, go mod tidy alone should probably suffice.