go1.11 module cannot find module for path xxx.xxx (user defined packages)

[xiaokugua250]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.11 windows/amd64

Does this issue reproduce with the latest release?

No

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\Administrator\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=E:\WorksSpaces\GoWorkSpaces\clouds\cspentry\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\Administrator\AppData\Local\Temp\go-build799184
522=/tmp/go-build -gno-record-gcc-switches

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best
my project is like this

in general.go
package general
const VERSION = "V4.0"
the go.mod in general is
module cloudms.general

the go.mod in cspenrty is
module cloudms.cspentry
require cloudms.general v1.0.0
replace cloudms.general v1.0.0 => ../general

What did you expect to see?

compile success and output is hello world

What did you see instead?

build clouds/cspentry: cannot find module for path cloudms.general

[sanguohot]

Well the same to me. I am using a self defined package.
It seems 'windows7 amd64' do not work with GO111MODULE=auto, but work with GO111MODULE=on.
This is my test case:

E:\evan\goland\src\ethereum-abi>set GO111MODULE=on

E:\evan\goland\src\ethereum-abi>go build .
go: finding github.com/go-stack/stack v1.8.0
go: finding github.com/syndtr/goleveldb v0.0.0-20180815032940-ae2bd5eed72d
go: finding github.com/urfave/cli v1.20.0
go: finding github.com/ethereum/go-ethereum v1.8.15
go: finding github.com/pkg/errors v0.8.0
go: finding github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db
go: finding gopkg.in/karalabe/cookiejar.v2 v2.0.0-20150724131613-8dcd6a7f4951
go: downloading github.com/urfave/cli v1.20.0
go: downloading github.com/ethereum/go-ethereum v1.8.15
go: downloading github.com/pkg/errors v0.8.0
go: downloading gopkg.in/karalabe/cookiejar.v2 v2.0.0-20150724131613-8dcd6a7f495
1
go: downloading github.com/syndtr/goleveldb v0.0.0-20180815032940-ae2bd5eed72d
go: downloading github.com/go-stack/stack v1.8.0
go: downloading github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db

E:\evan\goland\src\ethereum-abi>set GO111MODULE=auto

E:\evan\goland\src\ethereum-abi>go run main.go
main.go:5:2: cannot find package "github.com/sanguohot/ethereum-abi/abi" in any
of:
D:\Go\src\github.com\sanguohot\ethereum-abi\abi (from $GOROOT)
E:\evan\goland\src\github.com\sanguohot\ethereum-abi\abi (from $GOPATH)

[sanguohot]

all right.
the error happened while my project in $GOPATH.
so just a mistake.
but I still think it is a bug because of the different behavior between "on" and "auto".

[oiooj]

The import path cloudms.general will be seen as a domain name, and go will stat it now.

[bcmills]

@sanguohot, GO111MODULE=auto toggles between on and off depending on two factors:

1. whether you are in GOPATH/src, and
2. whether there is a go.mod file in (a parent of) the current directory.

I'm guessing that your GOPATH is E:\evan\goland. If so, the difference in behavior is completely expected.

[sanguohot]

@bcmills Yes it is E:\evan\goland.
But my project matchs the second factor, I think it should be handled with first priority.

[bcmills]

my project matchs the second factor, I think it should be handled with first priority.

In Go 1.11, we want it to be the case that bugs in module mode don't affect folks who are still using GOPATH. That implies that module mode within GOPATH must be an explicit opt-in.

[bcmills]

@xiaokugua250

build clouds/cspentry: cannot find module for path cloudms.general

What was the command-line for the build that failed, and in what directory was it invoked?

The go tool walks upward from its current working directory to find the go.mod file for the current module. Since you have (at least) three go.mod files sitting around, your “workspace” is semantically more like three separate module workspaces. While we do need to eventually support editing multiple modules together (#27542), I doubt it will ever be a good default way to structure a project. Instead, prefer a single go.mod at the root of your workspace, and invoke all go commands within that subtree of the filesystem.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[52fhy]

export GO111MODULE=on