Go: cmd/go: should 'go mod init' suggest (or run) 'go mod tidy'?

[bcmills]

(This issue is a follow-on to #40728, based on a discussion with @dr2chase.)

Now that we're defaulting to -mod=readonly, users who create a module from existing source code will generally need to run go mod tidy before they can actually build the packages in the module.

• Should go mod init check for source files and suggest that command?
• Should go mod init go ahead and tidy the module itself? (We don't know whether the user intends to prune out some nested modules before tidying, but nested modules should be rare anyway.)

CC @jayconrod @matloob

[dr2chase]

We could instead tie this to go build -- if go build sees no go.mod, and fails to find packages, it could suggest running go mod init and then go mod tidy. If it sees go.mod, and it is in the just-ran-go-init state, and fails to find packages, it could suggest running go mod tidy.

[bcmills]

@dr2chase, as of CL 258298, go build will suggest running go get to obtain the missing package, although I suppose in theory we could further distinguish whether the importer is in the main module and suggest go mod tidy instead in that case.

[bcmills]

Hmm, but that's a good point: we should _not_ suggest go get or go mod tidy if we are not working within a module.

[jayconrod]

I think go mod init should suggest go mod tidy if the directory is not empty and we aren't importing a configuration file from a vendoring tool. If the directory is empty, the user is creating a new project, and go mod tidy won't do anything yet. If we're importing a configuration file, go mod tidy might make sense, but we'll probably want different wording for the message.

I don't think go mod init should run go mod tidy automatically. It's almost always the next step, but I think if we keep those two commands discrete, users will be better able to understand their purposes. Users will learn that go mod tidy is the command that fixes dependencies. I'd be worried about people forgetting go mod tidy, then deleting go.mod and running go mod init again to fix dependencies.

[jayconrod]

Something I noticed yesterday: when go mod init imports a vendoring configuration file (like Gopkg.lock), it translates the requirements pretty directly without fetching go.mod files or upgrading things for consistency with MVS. This conflicts with the new -mod=readonly default: you tend to start out with an inconsistent go.mod file, and you can't do anything until you run go mod tidy.

I still think go mod tidy should be an extra step, but go mod init should at least ensure an imported go.mod is consistent.

[gopherbot]

Change https://golang.org/cl/264623 mentions this issue: cmd/go: in 'go mod init', ensure imported requirements are consistent

[gopherbot]

Change https://golang.org/cl/264622 mentions this issue: cmd/go: in 'go mod init', suggest running 'go mod tidy'

[gopherbot]

Change https://golang.org/cl/264621 mentions this issue: cmd/go: refactor modload.InitMod