diff options
author | Russ Cox <rsc@golang.org> | 2018-07-28 20:25:06 -0400 |
---|---|---|
committer | Russ Cox <rsc@golang.org> | 2018-08-01 00:35:17 +0000 |
commit | 6121987a10b2c54bc4c48473353205753d91f807 (patch) | |
tree | fcbb2090efe8a86daea4408d875adfe60d112238 /src/cmd/go/internal/modcmd/init.go | |
parent | 16962faf998a2f84793c5ca8481f6686ae9e3024 (diff) | |
download | go-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/modcmd/init.go')
-rw-r--r-- | src/cmd/go/internal/modcmd/init.go | 41 |
1 files changed, 41 insertions, 0 deletions
diff --git a/src/cmd/go/internal/modcmd/init.go b/src/cmd/go/internal/modcmd/init.go new file mode 100644 index 0000000000..f510a46262 --- /dev/null +++ b/src/cmd/go/internal/modcmd/init.go @@ -0,0 +1,41 @@ +// Copyright 2018 The Go Authors. All rights reserved. +// Use of this source code is governed by a BSD-style +// license that can be found in the LICENSE file. + +// go mod init + +package modcmd + +import ( + "cmd/go/internal/base" + "cmd/go/internal/modload" + "os" +) + +var cmdInit = &base.Command{ + UsageLine: "go mod init [module]", + Short: "initialize new module in current directory", + Long: ` +Init initializes and writes a new go.mod to the current directory, +in effect creating a new module rooted at the current directory. +The file go.mod must not already exist. +If possible, init will guess the module path from import comments +(see 'go help importpath') or from version control configuration. +To override this guess, supply the module path as an argument. + `, + Run: runInit, +} + +func runInit(cmd *base.Command, args []string) { + modload.CmdModInit = true + if len(args) > 1 { + base.Fatalf("go mod init: too many arguments") + } + if len(args) == 1 { + modload.CmdModModule = args[0] + } + if _, err := os.Stat("go.mod"); err == nil { + base.Fatalf("go mod init: go.mod already exists") + } + modload.InitMod() // does all the hard work +} |