aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/go/internal/get/get.go
diff options
context:
space:
mode:
authorRuss Cox <rsc@golang.org>2018-07-28 20:25:06 -0400
committerRuss Cox <rsc@golang.org>2018-08-01 00:35:17 +0000
commit6121987a10b2c54bc4c48473353205753d91f807 (patch)
treefcbb2090efe8a86daea4408d875adfe60d112238 /src/cmd/go/internal/get/get.go
parent16962faf998a2f84793c5ca8481f6686ae9e3024 (diff)
downloadgo-6121987a10b2c54bc4c48473353205753d91f807.tar.gz
go-6121987a10b2c54bc4c48473353205753d91f807.zip
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>
Diffstat (limited to 'src/cmd/go/internal/get/get.go')
-rw-r--r--src/cmd/go/internal/get/get.go2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/cmd/go/internal/get/get.go b/src/cmd/go/internal/get/get.go
index 0789d5bb3c..fd97c6dcb6 100644
--- a/src/cmd/go/internal/get/get.go
+++ b/src/cmd/go/internal/get/get.go
@@ -23,7 +23,7 @@ import (
)
var CmdGet = &base.Command{
- UsageLine: "get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages]",
+ UsageLine: "go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages]",
Short: "download and install packages and dependencies",
Long: `
Get downloads the packages named by the import paths, along with their