From eca5c83a3e8b926d663b6a824c76b4dadac7b66d Mon Sep 17 00:00:00 2001 From: "Bryan C. Mills" Date: Wed, 13 Feb 2019 15:07:56 -0500 Subject: [PATCH] cmd/go: change the default value of GO111MODULE to 'on' This reverts CL 166985, restoring CL 162698. The bootstrap failure from CL 162698 was fixed in CL 167077 and CL 167078. Fixes #30228 Change-Id: I5a4e3081018c51b74b67185e64f20a9c824a564e Reviewed-on: https://go-review.googlesource.com/c/go/+/167087 Run-TryBot: Bryan C. Mills TryBot-Result: Gobot Gobot Reviewed-by: Jay Conrod --- src/cmd/go/alldocs.go | 331 +++++++++--------- src/cmd/go/help_test.go | 5 + src/cmd/go/internal/help/help.go | 7 +- src/cmd/go/internal/modload/help.go | 39 +-- src/cmd/go/internal/modload/init.go | 35 +- src/cmd/go/main.go | 15 +- src/cmd/go/mkalldocs.sh | 2 +- src/cmd/go/testdata/script/mod_find.txt | 2 +- .../go/testdata/script/mod_gobuild_import.txt | 6 + 9 files changed, 210 insertions(+), 232 deletions(-) diff --git a/src/cmd/go/alldocs.go b/src/cmd/go/alldocs.go index 6e8d60f4cd714..d037d86bff20f 100644 --- a/src/cmd/go/alldocs.go +++ b/src/cmd/go/alldocs.go @@ -21,7 +21,7 @@ // fix update packages to use new APIs // fmt gofmt (reformat) package sources // generate generate Go files by processing source -// get download and install packages and dependencies +// get add dependencies to current module and install them // install compile and install packages and dependencies // list list packages or modules // mod module maintenance @@ -534,67 +534,105 @@ // For more about specifying packages, see 'go help packages'. // // -// Download and install packages and dependencies +// Add dependencies to current module and install them // // Usage: // -// go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages] +// go get [-d] [-m] [-u] [-v] [-insecure] [build flags] [packages] // -// Get downloads the packages named by the import paths, along with their -// dependencies. It then installs the named packages, like 'go install'. +// Get resolves and adds dependencies to the current development module +// and then builds and installs them. // -// The -d flag instructs get to stop after downloading the packages; that is, -// it instructs get not to install the packages. +// The first step is to resolve which dependencies to add. // -// The -f flag, valid only when -u is set, forces get -u not to verify that -// each package has been checked out from the source control repository -// implied by its import path. This can be useful if the source is a local fork -// of the original. +// For each named package or package pattern, get must decide which version of +// the corresponding module to use. By default, get chooses the latest tagged +// release version, such as v0.4.5 or v1.2.3. If there are no tagged release +// versions, get chooses the latest tagged prerelease version, such as +// v0.0.1-pre1. If there are no tagged versions at all, get chooses the latest +// known commit. // -// The -fix flag instructs get to run the fix tool on the downloaded packages -// before resolving dependencies or building the code. +// This default version selection can be overridden by adding an @version +// suffix to the package argument, as in 'go get golang.org/x/text@v0.3.0'. +// For modules stored in source control repositories, the version suffix can +// also be a commit hash, branch identifier, or other syntax known to the +// source control system, as in 'go get golang.org/x/text@master'. +// The version suffix @latest explicitly requests the default behavior +// described above. // -// The -insecure flag permits fetching from repositories and resolving -// custom domains using insecure schemes such as HTTP. Use with caution. +// If a module under consideration is already a dependency of the current +// development module, then get will update the required version. +// Specifying a version earlier than the current required version is valid and +// downgrades the dependency. The version suffix @none indicates that the +// dependency should be removed entirely, downgrading or removing modules +// depending on it as needed. // -// The -t flag instructs get to also download the packages required to build -// the tests for the specified packages. +// Although get defaults to using the latest version of the module containing +// a named package, it does not use the latest version of that module's +// dependencies. Instead it prefers to use the specific dependency versions +// requested by that module. For example, if the latest A requires module +// B v1.2.3, while B v1.2.4 and v1.3.1 are also available, then 'go get A' +// will use the latest A but then use B v1.2.3, as requested by A. (If there +// are competing requirements for a particular module, then 'go get' resolves +// those requirements by taking the maximum requested version.) // -// The -u flag instructs get to use the network to update the named packages -// and their dependencies. By default, get uses the network to check out -// missing packages but does not use it to look for updates to existing packages. +// The -u flag instructs get to update dependencies to use newer minor or +// patch releases when available. Continuing the previous example, +// 'go get -u A' will use the latest A with B v1.3.1 (not B v1.2.3). // -// The -v flag enables verbose progress and debug output. +// The -u=patch flag (not -u patch) instructs get to update dependencies +// to use newer patch releases when available. Continuing the previous example, +// 'go get -u=patch A' will use the latest A with B v1.2.4 (not B v1.2.3). // -// Get also accepts build flags to control the installation. See 'go help build'. +// In general, adding a new dependency may require upgrading +// existing dependencies to keep a working build, and 'go get' does +// this automatically. Similarly, downgrading one dependency may +// require downgrading other dependencies, and 'go get' does +// this automatically as well. // -// When checking out a new package, get creates the target directory -// GOPATH/src/. If the GOPATH contains multiple entries, -// get uses the first one. For more details see: 'go help gopath'. +// The -m flag instructs get to stop here, after resolving, upgrading, +// and downgrading modules and updating go.mod. When using -m, +// each specified package path must be a module path as well, +// not the import path of a package below the module root. // -// When checking out or updating a package, get looks for a branch or tag -// that matches the locally installed version of Go. The most important -// rule is that if the local installation is running version "go1", get -// searches for a branch or tag named "go1". If no such version exists -// it retrieves the default branch of the package. +// The -insecure flag permits fetching from repositories and resolving +// custom domains using insecure schemes such as HTTP. Use with caution. // -// When go get checks out or updates a Git repository, -// it also updates any git submodules referenced by the repository. +// The second step is to download (if needed), build, and install +// the named packages. // -// Get never checks out or updates code stored in vendor directories. +// If an argument names a module but not a package (because there is no +// Go source code in the module's root directory), then the install step +// is skipped for that argument, instead of causing a build failure. +// For example 'go get golang.org/x/perf' succeeds even though there +// is no code corresponding to that import path. // -// For more about specifying packages, see 'go help packages'. +// Note that package patterns are allowed and are expanded after resolving +// the module versions. For example, 'go get golang.org/x/perf/cmd/...' +// adds the latest golang.org/x/perf and then installs the commands in that +// latest version. // -// For more about how 'go get' finds source code to -// download, see 'go help importpath'. +// The -d flag instructs get to download the source code needed to build +// the named packages, including downloading necessary dependencies, +// but not to build and install them. // -// This text describes the behavior of get when using GOPATH -// to manage source code and dependencies. -// If instead the go command is running in module-aware mode, -// the details of get's flags and effects change, as does 'go help get'. -// See 'go help modules' and 'go help module-get'. +// With no package arguments, 'go get' applies to the main module, +// and to the Go package in the current directory, if any. In particular, +// 'go get -u' and 'go get -u=patch' update all the dependencies of the +// main module. With no package arguments and also without -u, +// 'go get' is not much more than 'go install', and 'go get -d' not much +// more than 'go list'. // -// See also: go build, go install, go clean. +// For more about modules, see 'go help modules'. +// +// For more about specifying packages, see 'go help packages'. +// +// This text describes the behavior of get using modules to manage source +// code and dependencies. If instead the go command is running in GOPATH +// mode, the details of get's flags and effects change, as does 'go help get'. +// See 'go help modules' and 'go help gopath-get'. +// +// See also: go build, go install, go clean, go mod. // // // Compile and install packages and dependencies @@ -1840,6 +1878,72 @@ // See https://golang.org/s/go15vendor for details. // // +// Legacy GOPATH go get +// +// The 'go get' command changes behavior depending on whether the +// go command is running in module-aware mode or legacy GOPATH mode. +// This help text, accessible as 'go help gopath-get' even in module-aware mode, +// describes 'go get' as it operates in legacy GOPATH mode. +// +// Usage: go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages] +// +// Get downloads the packages named by the import paths, along with their +// dependencies. It then installs the named packages, like 'go install'. +// +// The -d flag instructs get to stop after downloading the packages; that is, +// it instructs get not to install the packages. +// +// The -f flag, valid only when -u is set, forces get -u not to verify that +// each package has been checked out from the source control repository +// implied by its import path. This can be useful if the source is a local fork +// of the original. +// +// The -fix flag instructs get to run the fix tool on the downloaded packages +// before resolving dependencies or building the code. +// +// The -insecure flag permits fetching from repositories and resolving +// custom domains using insecure schemes such as HTTP. Use with caution. +// +// The -t flag instructs get to also download the packages required to build +// the tests for the specified packages. +// +// The -u flag instructs get to use the network to update the named packages +// and their dependencies. By default, get uses the network to check out +// missing packages but does not use it to look for updates to existing packages. +// +// The -v flag enables verbose progress and debug output. +// +// Get also accepts build flags to control the installation. See 'go help build'. +// +// When checking out a new package, get creates the target directory +// GOPATH/src/. If the GOPATH contains multiple entries, +// get uses the first one. For more details see: 'go help gopath'. +// +// When checking out or updating a package, get looks for a branch or tag +// that matches the locally installed version of Go. The most important +// rule is that if the local installation is running version "go1", get +// searches for a branch or tag named "go1". If no such version exists +// it retrieves the default branch of the package. +// +// When go get checks out or updates a Git repository, +// it also updates any git submodules referenced by the repository. +// +// Get never checks out or updates code stored in vendor directories. +// +// For more about specifying packages, see 'go help packages'. +// +// For more about how 'go get' finds source code to +// download, see 'go help importpath'. +// +// This text describes the behavior of get when using GOPATH +// to manage source code and dependencies. +// If instead the go command is running in module-aware mode, +// the details of get's flags and effects change, as does 'go help get'. +// See 'go help modules' and 'go help module-get'. +// +// See also: go build, go install, go clean. +// +// // Module proxy protocol // // The go command by default downloads modules from version control systems @@ -2099,34 +2203,25 @@ // Modules replace the old GOPATH-based approach to specifying // which source files are used in a given build. // -// Preliminary module support +// Module support // -// Go 1.11 includes preliminary support for Go modules, -// including a new module-aware 'go get' command. -// We intend to keep revising this support, while preserving compatibility, -// until it can be declared official (no longer preliminary), -// and then at a later point we may remove support for work -// in GOPATH and the old 'go get' command. +// Go 1.13 includes official support for Go modules, +// including a module-aware 'go get' command. +// Module-aware mode is active by default. // -// The quickest way to take advantage of the new Go 1.11 module support -// is to check out your repository into a directory outside GOPATH/src, -// create a go.mod file (described in the next section) there, and run -// go commands from within that file tree. -// -// For more fine-grained control, the module support in Go 1.11 respects +// For more fine-grained control, Go 1.13 continues to respect // a temporary environment variable, GO111MODULE, which can be set to one -// of three string values: off, on, or auto (the default). -// If GO111MODULE=off, then the go command never uses the -// new module support. Instead it looks in vendor directories and GOPATH +// of three string values: off, auto, or on (the default). +// If GO111MODULE=on or is unset, then the go command requires the use of +// modules, never consulting GOPATH. We refer to this as the command +// being module-aware or running in "module-aware mode". +// If GO111MODULE=auto, then the go command enables or disables module +// support based on the current directory. Module support is enabled only +// when the current directory is outside GOPATH/src and itself contains a +// go.mod file or is below a directory containing a go.mod file. +// If GO111MODULE=off, then the go command never uses +// module support. Instead it looks in vendor directories and GOPATH // to find dependencies; we now refer to this as "GOPATH mode." -// If GO111MODULE=on, then the go command requires the use of modules, -// never consulting GOPATH. We refer to this as the command being -// module-aware or running in "module-aware mode". -// If GO111MODULE=auto or is unset, then the go command enables or -// disables module support based on the current directory. -// Module support is enabled only when the current directory is outside -// GOPATH/src and itself contains a go.mod file or is below a directory -// containing a go.mod file. // // In module-aware mode, GOPATH no longer defines the meaning of imports // during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod) @@ -2448,110 +2543,6 @@ // are still ignored. // // -// Module-aware go get -// -// The 'go get' command changes behavior depending on whether the -// go command is running in module-aware mode or legacy GOPATH mode. -// This help text, accessible as 'go help module-get' even in legacy GOPATH mode, -// describes 'go get' as it operates in module-aware mode. -// -// Usage: go get [-d] [-m] [-u] [-v] [-insecure] [build flags] [packages] -// -// Get resolves and adds dependencies to the current development module -// and then builds and installs them. -// -// The first step is to resolve which dependencies to add. -// -// For each named package or package pattern, get must decide which version of -// the corresponding module to use. By default, get chooses the latest tagged -// release version, such as v0.4.5 or v1.2.3. If there are no tagged release -// versions, get chooses the latest tagged prerelease version, such as -// v0.0.1-pre1. If there are no tagged versions at all, get chooses the latest -// known commit. -// -// This default version selection can be overridden by adding an @version -// suffix to the package argument, as in 'go get golang.org/x/text@v0.3.0'. -// For modules stored in source control repositories, the version suffix can -// also be a commit hash, branch identifier, or other syntax known to the -// source control system, as in 'go get golang.org/x/text@master'. -// The version suffix @latest explicitly requests the default behavior -// described above. -// -// If a module under consideration is already a dependency of the current -// development module, then get will update the required version. -// Specifying a version earlier than the current required version is valid and -// downgrades the dependency. The version suffix @none indicates that the -// dependency should be removed entirely, downgrading or removing modules -// depending on it as needed. -// -// Although get defaults to using the latest version of the module containing -// a named package, it does not use the latest version of that module's -// dependencies. Instead it prefers to use the specific dependency versions -// requested by that module. For example, if the latest A requires module -// B v1.2.3, while B v1.2.4 and v1.3.1 are also available, then 'go get A' -// will use the latest A but then use B v1.2.3, as requested by A. (If there -// are competing requirements for a particular module, then 'go get' resolves -// those requirements by taking the maximum requested version.) -// -// The -u flag instructs get to update dependencies to use newer minor or -// patch releases when available. Continuing the previous example, -// 'go get -u A' will use the latest A with B v1.3.1 (not B v1.2.3). -// -// The -u=patch flag (not -u patch) instructs get to update dependencies -// to use newer patch releases when available. Continuing the previous example, -// 'go get -u=patch A' will use the latest A with B v1.2.4 (not B v1.2.3). -// -// In general, adding a new dependency may require upgrading -// existing dependencies to keep a working build, and 'go get' does -// this automatically. Similarly, downgrading one dependency may -// require downgrading other dependencies, and 'go get' does -// this automatically as well. -// -// The -m flag instructs get to stop here, after resolving, upgrading, -// and downgrading modules and updating go.mod. When using -m, -// each specified package path must be a module path as well, -// not the import path of a package below the module root. -// -// The -insecure flag permits fetching from repositories and resolving -// custom domains using insecure schemes such as HTTP. Use with caution. -// -// The second step is to download (if needed), build, and install -// the named packages. -// -// If an argument names a module but not a package (because there is no -// Go source code in the module's root directory), then the install step -// is skipped for that argument, instead of causing a build failure. -// For example 'go get golang.org/x/perf' succeeds even though there -// is no code corresponding to that import path. -// -// Note that package patterns are allowed and are expanded after resolving -// the module versions. For example, 'go get golang.org/x/perf/cmd/...' -// adds the latest golang.org/x/perf and then installs the commands in that -// latest version. -// -// The -d flag instructs get to download the source code needed to build -// the named packages, including downloading necessary dependencies, -// but not to build and install them. -// -// With no package arguments, 'go get' applies to the main module, -// and to the Go package in the current directory, if any. In particular, -// 'go get -u' and 'go get -u=patch' update all the dependencies of the -// main module. With no package arguments and also without -u, -// 'go get' is not much more than 'go install', and 'go get -d' not much -// more than 'go list'. -// -// For more about modules, see 'go help modules'. -// -// For more about specifying packages, see 'go help packages'. -// -// This text describes the behavior of get using modules to manage source -// code and dependencies. If instead the go command is running in GOPATH -// mode, the details of get's flags and effects change, as does 'go help get'. -// See 'go help modules' and 'go help gopath-get'. -// -// See also: go build, go install, go clean, go mod. -// -// // Package lists and patterns // // Many commands apply to a set of packages: diff --git a/src/cmd/go/help_test.go b/src/cmd/go/help_test.go index ec6a9d11cbe2e..9c0fa8411ee13 100644 --- a/src/cmd/go/help_test.go +++ b/src/cmd/go/help_test.go @@ -12,9 +12,14 @@ import ( "testing" "cmd/go/internal/help" + "cmd/go/internal/modload" ) func TestDocsUpToDate(t *testing.T) { + if !modload.Enabled() { + t.Skipf("help.Help in GOPATH mode is configured by main.main") + } + buf := new(bytes.Buffer) // Match the command in mkalldocs.sh that generates alldocs.go. help.Help(buf, []string{"documentation"}) diff --git a/src/cmd/go/internal/help/help.go b/src/cmd/go/internal/help/help.go index 121deb70a5890..d373771ab5a74 100644 --- a/src/cmd/go/internal/help/help.go +++ b/src/cmd/go/internal/help/help.go @@ -17,6 +17,7 @@ import ( "unicode/utf8" "cmd/go/internal/base" + "cmd/go/internal/modload" ) // Help implements the 'help' command. @@ -35,8 +36,10 @@ func Help(w io.Writer, args []string) { usage := &base.Command{Long: buf.String()} cmds := []*base.Command{usage} for _, cmd := range base.Go.Commands { - if cmd.UsageLine == "gopath-get" { - // Avoid duplication of the "get" documentation. + // Avoid duplication of the "get" documentation. + if cmd.UsageLine == "module-get" && modload.Enabled() { + continue + } else if cmd.UsageLine == "gopath-get" && !modload.Enabled() { continue } cmds = append(cmds, cmd) diff --git a/src/cmd/go/internal/modload/help.go b/src/cmd/go/internal/modload/help.go index 63657a448fbdf..c1685ff08e372 100644 --- a/src/cmd/go/internal/modload/help.go +++ b/src/cmd/go/internal/modload/help.go @@ -19,34 +19,25 @@ including recording and resolving dependencies on other modules. Modules replace the old GOPATH-based approach to specifying which source files are used in a given build. -Preliminary module support +Module support -Go 1.11 includes preliminary support for Go modules, -including a new module-aware 'go get' command. -We intend to keep revising this support, while preserving compatibility, -until it can be declared official (no longer preliminary), -and then at a later point we may remove support for work -in GOPATH and the old 'go get' command. +Go 1.13 includes official support for Go modules, +including a module-aware 'go get' command. +Module-aware mode is active by default. -The quickest way to take advantage of the new Go 1.11 module support -is to check out your repository into a directory outside GOPATH/src, -create a go.mod file (described in the next section) there, and run -go commands from within that file tree. - -For more fine-grained control, the module support in Go 1.11 respects +For more fine-grained control, Go 1.13 continues to respect a temporary environment variable, GO111MODULE, which can be set to one -of three string values: off, on, or auto (the default). -If GO111MODULE=off, then the go command never uses the -new module support. Instead it looks in vendor directories and GOPATH +of three string values: off, auto, or on (the default). +If GO111MODULE=on or is unset, then the go command requires the use of +modules, never consulting GOPATH. We refer to this as the command +being module-aware or running in "module-aware mode". +If GO111MODULE=auto, then the go command enables or disables module +support based on the current directory. Module support is enabled only +when the current directory is outside GOPATH/src and itself contains a +go.mod file or is below a directory containing a go.mod file. +If GO111MODULE=off, then the go command never uses +module support. Instead it looks in vendor directories and GOPATH to find dependencies; we now refer to this as "GOPATH mode." -If GO111MODULE=on, then the go command requires the use of modules, -never consulting GOPATH. We refer to this as the command being -module-aware or running in "module-aware mode". -If GO111MODULE=auto or is unset, then the go command enables or -disables module support based on the current directory. -Module support is enabled only when the current directory is outside -GOPATH/src and itself contains a go.mod file or is below a directory -containing a go.mod file. In module-aware mode, GOPATH no longer defines the meaning of imports during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod) diff --git a/src/cmd/go/internal/modload/init.go b/src/cmd/go/internal/modload/init.go index af7ce070ce5ed..d0beb6e747390 100644 --- a/src/cmd/go/internal/modload/init.go +++ b/src/cmd/go/internal/modload/init.go @@ -33,7 +33,7 @@ import ( var ( cwd string // TODO(bcmills): Is this redundant with base.Cwd? - MustUseModules = mustUseModules() + mustUseModules = true initialized bool modRoot string @@ -78,16 +78,6 @@ func BinDir() string { return filepath.Join(gopath, "bin") } -// mustUseModules reports whether we are invoked as vgo -// (as opposed to go). -// If so, we only support builds with go.mod files. -func mustUseModules() bool { - name := os.Args[0] - name = name[strings.LastIndex(name, "/")+1:] - name = name[strings.LastIndex(name, `\`)+1:] - return strings.HasPrefix(name, "vgo") -} - var inGOPATH bool // running in GOPATH/src // Init determines whether module mode is enabled, locates the root of the @@ -104,14 +94,13 @@ func Init() { switch env { default: base.Fatalf("go: unknown environment setting GO111MODULE=%s", env) - case "", "auto": - // leave MustUseModules alone - case "on": - MustUseModules = true + case "auto": + mustUseModules = false + case "on", "": + mustUseModules = true case "off": - if !MustUseModules { - return - } + mustUseModules = false + return } // Disable any prompting for passwords by Git. @@ -158,7 +147,7 @@ func Init() { } } - if inGOPATH && !MustUseModules { + if inGOPATH && !mustUseModules { if CmdModInit { die() // Don't init a module that we're just going to ignore. } @@ -175,8 +164,8 @@ func Init() { } else { modRoot = findModuleRoot(cwd) if modRoot == "" { - if !MustUseModules { - // GO111MODULE is 'auto' (or unset), and we can't find a module root. + if !mustUseModules { + // GO111MODULE is 'auto', and we can't find a module root. // Stay in GOPATH mode. return } @@ -275,7 +264,7 @@ func init() { // (usually through MustModRoot). func Enabled() bool { Init() - return modRoot != "" || MustUseModules + return modRoot != "" || mustUseModules } // ModRoot returns the root of the main module. @@ -308,7 +297,7 @@ func die() { if os.Getenv("GO111MODULE") == "off" { base.Fatalf("go: modules disabled by GO111MODULE=off; see 'go help modules'") } - if inGOPATH && !MustUseModules { + if inGOPATH && !mustUseModules { base.Fatalf("go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'") } if cwd != "" { diff --git a/src/cmd/go/main.go b/src/cmd/go/main.go index acca4fd3c1f7e..e529e96986eb9 100644 --- a/src/cmd/go/main.go +++ b/src/cmd/go/main.go @@ -49,7 +49,7 @@ func init() { fix.CmdFix, fmtcmd.CmdFmt, generate.CmdGenerate, - get.CmdGet, + modget.CmdGet, work.CmdInstall, list.CmdList, modcmd.CmdMod, @@ -89,17 +89,10 @@ func main() { base.Usage() } - if modload.MustUseModules { - // If running with modules force-enabled, change get now to change help message. - *get.CmdGet = *modget.CmdGet - } - if args[0] == "get" || args[0] == "help" { - // Replace get with module-aware get if appropriate. - // Note that if MustUseModules is true, this happened already above, - // but no harm in doing it again. - if modload.Init(); modload.Enabled() { - *get.CmdGet = *modget.CmdGet + if modload.Init(); !modload.Enabled() { + // Replace module-aware get with GOPATH get if appropriate. + *modget.CmdGet = *get.CmdGet } } diff --git a/src/cmd/go/mkalldocs.sh b/src/cmd/go/mkalldocs.sh index f37d59d2d7431..a2b0aca3c9da6 100755 --- a/src/cmd/go/mkalldocs.sh +++ b/src/cmd/go/mkalldocs.sh @@ -8,6 +8,6 @@ set -e go build -o go.latest # If the command used to generate alldocs.go changes, update TestDocsUpToDate in # help_test.go. -./go.latest help documentation >alldocs.go +GO111MODULE='' ./go.latest help documentation >alldocs.go gofmt -w alldocs.go rm go.latest diff --git a/src/cmd/go/testdata/script/mod_find.txt b/src/cmd/go/testdata/script/mod_find.txt index 703a88e99c9a8..e82001a24ab19 100644 --- a/src/cmd/go/testdata/script/mod_find.txt +++ b/src/cmd/go/testdata/script/mod_find.txt @@ -17,7 +17,7 @@ cd $GOPATH/src/example.com/x/y ! go mod init stderr 'go: modules disabled inside GOPATH/src by GO111MODULE=auto; see ''go help modules''' -env GO111MODULE=on +env GO111MODULE= # Derive module path from location inside GOPATH. cd $GOPATH/src/example.com/x/y diff --git a/src/cmd/go/testdata/script/mod_gobuild_import.txt b/src/cmd/go/testdata/script/mod_gobuild_import.txt index d2d1645b838ed..6c87d59649242 100644 --- a/src/cmd/go/testdata/script/mod_gobuild_import.txt +++ b/src/cmd/go/testdata/script/mod_gobuild_import.txt @@ -24,12 +24,18 @@ exec $WORK/testimport.exe other/x/y/z/w . stdout w2.go # GO111MODULE=on outside GOPATH/src +env GO111MODULE= +exec $WORK/testimport.exe other/x/y/z/w . +stdout w2.go env GO111MODULE=on exec $WORK/testimport.exe other/x/y/z/w . stdout w2.go # GO111MODULE=on in GOPATH/src cd $GOPATH/src +env GO111MODULE= +exec $WORK/testimport.exe x/y/z/w . +stdout w1.go env GO111MODULE=on exec $WORK/testimport.exe x/y/z/w . stdout w1.go