cmd/go: split go mod into multiple subcommands

The current "go mod" command does too many things.
The design is unclear.

It looks like "everything you might want to do with modules"
which causes people to think all module operations go through
"go mod", which is the opposite of the seamless integration we're
going for. In particular too many people think "go mod -require"
and "go get" are the same.

It does make sense to put the module-specific functionality
under "go mod", but not as flags. Instead, split "go mod" into
multiple subcommands:

	go mod edit   # old go mod -require ...
	go mod fix    # old go mod -fix
	go mod graph  # old go mod -graph
	go mod init   # old go mod -init
	go mod tidy   # old go mod -sync
	go mod vendor # old go mod -vendor
	go mod verify # old go mod -verify

Splitting out the individual commands makes both the docs
and the implementations dramatically easier to read.
It simplifies the command lines
(go mod -init -module m is now 'go mod init m')
and allows command-specific flags.

We've avoided subcommands in the go command to date, and we
should continue to avoid adding them unless it really makes
the experience significantly better. In this case, it does.

Creating subcommands required some changes in the core
command-parsing and help logic to generalize from one
level to multiple levels.

As part of having "go mod init" be a separate command,
this CL changes the failure behavior during module initialization
to be delayed until modules are actually needed.
Initialization can still happen early, but the base.Fatalf
is delayed until something needs to use modules.
This fixes a bunch of commands like 'go env' that were
unhelpfully failing with GO111MODULE=on when not in a
module directory.

Fixes #26432.
Fixes #26581.
Fixes #26596.
Fixes #26639.

Change-Id: I868db0babe8c288e8af684b29d4a5ae4825d6407
Reviewed-on: https://go-review.googlesource.com/126655
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

1 files changed, 6 insertions, 6 deletions

diff --git a/src/cmd/go/internal/modload/help.go b/src/cmd/go/internal/modload/help.go
index 3efa708f0b..fbc7374c7c 100644
--- a/src/cmd/go/internal/modload/help.go
+++ b/src/cmd/go/internal/modload/help.go
@@ -85,12 +85,12 @@ For more about the go.mod file, see https://research.swtch.com/vgo-module.
 
 To start a new module, simply create a go.mod file in the root of the
 module's directory tree, containing only a module statement.
-The 'go mod' command can be used to do this:
+The 'go mod init' command can be used to do this:
 
-	go mod -init -module example.com/m
+	go mod init example.com/m
 
 In a project already using an existing dependency management tool like
-godep, glide, or dep, 'go mod -init' will also add require statements
+godep, glide, or dep, 'go mod init' will also add require statements
 matching the existing configuration.
 
 Once the go.mod file exists, no additional steps are required:
@@ -147,7 +147,7 @@ package from the module. On the other hand, determining that a module requiremen
 is no longer necessary and can be deleted requires a full view of
 all packages in the module, across all possible build configurations
 (architectures, operating systems, build tags, and so on).
-The 'go mod -sync' command builds that view and then
+The 'go mod tidy' command builds that view and then
 adds any missing module requirements and removes unnecessary ones.
 
 As part of maintaining the require statements in go.mod, the go command
@@ -337,7 +337,7 @@ The go command maintains a cache of downloaded packages and computes
 and records the cryptographic checksum of each package at download time.
 In normal operation, the go command checks these pre-computed checksums
 against the main module's go.sum file, instead of recomputing them on
-each command invocation. The 'go mod -verify' command checks that
+each command invocation. The 'go mod verify' command checks that
 the cached copies of module downloads still match both their recorded
 checksums and the entries in go.sum.
 
@@ -356,7 +356,7 @@ By default, the go command satisfies dependencies by downloading modules
 from their sources and using those downloaded copies (after verification,
 as described in the previous section). To allow interoperation with older
 versions of Go, or to ensure that all files used for a build are stored
-together in a single file tree, 'go mod -vendor' creates a directory named
+together in a single file tree, 'go mod vendor' creates a directory named
 vendor in the root directory of the main module and stores there all the
 packages from dependency modules that are needed to support builds and
 tests of packages in the main module.