cmd/go: suggest 'go get' not 'go mod tidy'

[rsc]

A real message:

fixup.go:6:2: no required module provides package 9fans.net/go/draw; try 'go mod tidy' to add it

This message will lead to overuse of go mod tidy, with all the "unexpected magic" we are trying to avoid by not automatically updating go.mod. The suggestion should be that users actually add the dependencies they need, either with 'go get' (no args) in the directory or 'go get 9fans.net/go/draw' (the specific package).

It would also be nice to show the command in an easily copy-pastable form. So my suggestion is:

fixup.go:6:2: no required module provides package 9fans.net/go/draw; to add it:
	go get 9fans.net/go/draw

This is a release blocker because the message is new in Go 1.16 and will be seen frequently.

[gopherbot]

Change https://golang.org/cl/280713 mentions this issue: cmd/go: make module suggestion more friendly

[jayconrod]

Looked into this a bit today. We print hints to run go mod tidy in these cases:

1. go mod init is run on an existing project (with .go files) and no vendor configuration file (like Gopkg.lock) is imported. Let's keep this one. go mod init produces a go.mod file with no requirements, which may not be useful until go mod tidy is run. We discussed fusing the two commands in cmd/go: should 'go mod init' suggest (or run) 'go mod tidy'? #41712, but leaned away from doing that. I'll close that issue.
2. Unknown changes to go.mod or go.sum are needed. If we can recommend a specific go get or go mod download command, we already do that, so this is a catch-all message.
3. Any module-aware command is run that names a package not provided by any module in the build list or any package that imports such a package and the missing package is known to be in all. Typically, that means the import declaration is in a package in the main module.

• If the missing package is not known to be in all, we recommend go get -d $missingpkg instead.

Focusing on (3), I agree it's better to recommend go get $missingpkg. For completeness, there are a couple disadvantages.

• go get adds an // indirect requirement if it doesn't know the package is in all. That shouldn't cause errors though.
• If the module is replaced but not required, go get will go out to the network to look for other versions. It should add a requirement on the highest replaced version or v0.0.0-00010101000000-000000000000 if no specific version is replaced. We could probably modify go get to work a little more smoothly here.

Dropping the -d flag sounds fine (filed separately as #43523), as does printing commands on a separate line.

cc @bcmills @matloob

[bcmills]

• go get adds an // indirect requirement if it doesn't know the package is in all.

That might be a reasonable argument to suggest go get $importer instead of go get $importee, though?

(But I agree that either of those seems less disruptive than go mod tidy.)

[jayconrod]

Maybe... though that might also upgrade $importer if we didn't specify its version.

[bcmills]

Right. So $importer would have to be some (possibly-transitive) package in the main module, or else we would need to include an explicit version for it. Maybe not worth the complexity just to avoid a spurious comment that go mod tidy will remove.

[jayconrod]

Before closing this, I'll go through all our command-line hints and verify they're in the same format and appropriate for the situation.

From a comment in CL 280713, we should recommend go mod download instead of go mod tidy when a sum is missing for an imported package. I need to verify that does the right thing first though.

[gopherbot]

Change https://golang.org/cl/282121 mentions this issue: cmd/go: make hints in error messages more consistent