/cc @jayconrod @bcmills

I think this is working as intended.

The go command will look for a go.mod file in the current directory or a parent directory (regardless of command line arguments). If one is found, that defines "main module", and it's the only go.mod file that may be updated. If GO111MODULE is auto or is not set, this also determines whether module aware mode is enabled.

Relative paths are described in go help packages. A relative or absolute path is interpreted as a directory, not a package name. The go command may go out to the network to download modules to satisfy imports in that directory or to fill in anything missing from the cache. It won't look $GOPATH/src in module aware mode though.

Well...that is curious. The package did have a go.mod file, and it was ignored. The entire go install process ignored the go.mod files -- but simply changing the install command to be inside the directory triggered module=on behavior. So two different forms of the "go install" command cause different results: one ignores the go.mod files and does a local disk compile and the other recognizes the modules and goes out to github.com to resolve the imports, etc.

And look at "go help gopath":

"GOPATH and Modules

When using modules, GOPATH is no longer used for resolving imports.
However, it is still used to store downloaded source code (in GOPATH/pkg/mod)
and compiled commands (in GOPATH/bin)."

So if Go had been using modules it would have ignored the gopath/src and gone out to github to get the imports. I have tested this and that is the way it works.

If you think it works as intended, then that is fine with me. It just doesn't seem to match the documentation.

From "go help packages"

An import path that is a rooted path or that begins with a . or .. element is interpreted as a file system path and denotes the package in that directory.

Otherwise, the import path P denotes the package found in the directory DIR/src/P for some DIR listed in the GOPATH environment variable (For more details see: 'go help gopath').

I think that is pretty clear: it "denotes the package found in that directory". And in my case, that package had a go.mod file. Which was ignored. To take the alternative reading of the documentation would be to say: 'Fire up the command line and enter "go install github.com/userid/repo/pkgname" and if the user's home directory has a go.mod file that is what will be input to go install.' Would that be reasonable behavior?

go help modules has more information on this:

Go 1.13 includes support for Go modules. Module-aware mode is active by default whenever a go.mod file is found in, or in a parent of, the current directory.

The quickest way to take advantage of module support is to check out your repository, 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, 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=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=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=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 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) and installed commands (in GOPATH/bin, unless GOBIN is set).

OK, thank you for explaining that.