cmd/go: 'go test' does not reject a relative path spanning a module boundary

[FiloSottile]

In golang.org/x/exp there's a golang.org/x/exp/notary submodule.

I was making changes in golang.org/x/exp/notary/internal/note, and I ran the tests as go test ./notary/internal/note. If it weren't for the fact that my cache was missing some modules, leading to a go: extracting golang.org/x/exp/notary message, I would not have known I was testing the upstream code downloaded from the Internet instead of the new code on my machine.

$ pwd
~/src/golang.org/x/exp

$ go test ./notary/internal/note
go: finding golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6
go: finding golang.org/x/sys v0.0.0-20190312061237-fead79001313
go: finding golang.org/x/image v0.0.0-20190227222117-0694c2d4d067
go: finding golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846
go: finding golang.org/x/exp/notary v0.0.0-20190316020145-860388717186
go: finding github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802
go: finding golang.org/x/text v0.3.0
go: finding golang.org/x/crypto v0.0.0-20190313024323-a1f597ede03a
go: finding golang.org/x/net v0.0.0-20190311183353-d8887717615a
go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
go: downloading golang.org/x/exp/notary v0.0.0-20190316020145-860388717186
go: extracting golang.org/x/exp/notary v0.0.0-20190316020145-860388717186
go: downloading golang.org/x/crypto v0.0.0-20190313024323-a1f597ede03a
go: extracting golang.org/x/crypto v0.0.0-20190313024323-a1f597ede03a
ok  	golang.org/x/exp/notary/internal/note	0.058s

$ cd notary
$ go test ./internal/note
--- FAIL: TestSurprise (0.00s)
    note_test.go:191: surprise!
FAIL
FAIL	golang.org/x/exp/notary/internal/note	0.049s

Even worse, you could imagine running go build or go install with the same relative path, and the changes on disk wouldn't be reflected, which sounds a lot like the most frustrating experiences I've had with some web development setups.

There is a solution to this which is to add a replace directive in the golang.org/x/exp go.mod pointing to ./notary, but I don't even know if an unused replace is legal or effective. And anyway, it feels like something most projects will only discover painfully.

(There was one other sign that something went wrong: golang.org/x/exp/notary showed up in the golang.org/x/exp go.mod file, but that would not have happened if it were already there. In that case it should really have had a replace, because otherwise a similar issue would happen with golang.org/x/exp using the unmodified dependency, but again, this is a painful default and it's not clear how one is supposed to learn about the solution.)

/cc @bcmills

[thepudds]

Seems this should be an error? At least, that would be my personal expectation...

CC @jayconrod

[dmitshur]

https://golang.org/cmd/go/#hdr-The_main_module_and_the_build_list says:

The "main module" is the module containing the directory where the go command is run. The go command finds the module root by looking for a go.mod in the current directory, or else the current directory's parent directory, or else the parent's parent directory, and so on.

So, when you're in ~/src/golang.org/x/exp directory, go test <any arguments> using the golang.org/x/exp as the main module is consistent with the documented behavior.

It seems like the behavior is very unintuitive when the go command is run in one module, but but the package specified on the command line is outside of that module.

[jayconrod]

I agree this is a bug and we should show an error for it.

File system paths (including relative paths) are allowed to reference directories in the main module and in other modules in the build list. Without a file system replace directive, you should only be allowed to reference directories in $GOPATH/pkg/mod (editors need to do this).

[bcmills]

Without a file system replace directive, you should only be allowed to reference directories in $GOPATH/pkg/mod (editors need to do this).

It's not the presence in GOPATH/pkg/mod that matters: rather, it is the difference between relative and absolute paths. Absolute paths can be anything in the build list. Relative paths are supposed to be confined to within the same module (the bug here).

[bcmills]

I don't even know if an unused replace is legal or effective.

It is legal and has no effect. We are considering removing ineffective directives in go mod tidy; see #30516.

[gopherbot]

Change https://golang.org/cl/185345 mentions this issue: cmd/go: rationalize errors in internal/load and internal/modload