cmd/go: workspace detected outside of workspace

[leitzler]

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

$ go version
go version devel go1.19-914195c132 Thu Mar 10 21:10:30 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?

At least current gotip.

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

go env Output

$ go env
N/A

What did you do?

I created a workspace using go work init a level below an existing module and then tried to run my existing module.
e.g. with:

-- foo/go.mod --
module foo

go 1.19
-- foo/main.go --
package main

func main() {}
-- go.work --
go 1.19

Inside of foo I ran:

$ go build .
go: no modules were found in the current workspace; see 'go help work'
$ go run .
go: no modules were found in the current workspace; see 'go help work'
$ go list -m all
go: cannot match "all": go.mod file not found in current directory or any parent directory; see 'go help modules'

What did you expect to see? / What did you see instead?

Since my module isn't a part of the workspace I expect it to run/build.
The error messages for build and run do point me in the right direction, but if I instead have a slightly different scenario where I just forget (or don't know that I should) add foo to my go.work file:

-- a/a.go --
package a

const A = 1
-- a/go.mod --
module a

go 1.19
-- b/b.go --
package b

const B = 2
-- b/go.mod --
module b

go 1.19
-- foo/go.mod --
module foo

go 1.19
-- foo/main.go --
package main

import (
	"a"
	"b"
)

func main() {
	println(a.A)
	println(b.B)
}
-- go.work --
go 1.19

use (
	./a
	./b
)

Then gopls actually works as expected (can dereference a.A in main.go etc), but building/running fails with a more confusing error message:

$ go run .
go: no packages loaded from .
$ go list -m all
a
b
$ go build .
directory . outside modules listed in go.work or their selected dependencies

Again I would expect it to not use workspace mode since the module itself isn't a part of the workspace (or drop an error and refuse to build/run).
The benefits of not using workspace mode in this case would be that the tooling (e.g. gopls) wouldn't resolve the packages so it gets obvious to the user that something is wrong.
On the other side, if the workspace for example replace a version, things gets more subtle and that speaks in favor of erroring out.

[leitzler]

//cc @bcmills & @matloob

[cuiweixie]

you still need go.mod, though you have go.work

[matloob]

How about if go run . and go build .'s error messages included an extra sentence that said something like this: Current directory is contained in a module that is not part of the workspace. You can add the module to the workspace using go add .?

[gopherbot]

Change https://go.dev/cl/400014 mentions this issue: cmd/go: add a better error message when in a module outside workspace

[bcmills]

Looks like this fix was incomplete: go build does report the expanded error, but for some reason go run does not.

foo$ txtar ../*
Enter comment:
-- ../a/a.go --
package a

const A = 1
-- ../a/go.mod --
module a

go 1.19
-- ../b/b.go --
package b

const B = 2
-- ../b/go.mod --
module b

go 1.19
-- ../foo/go.mod --
module foo

go 1.19
-- ../foo/main.go --
package main

import (
        "a"
        "b"
)

func main() {
        println(a.A)
        println(b.B)
}
-- ../go.mod --
module example

go 1.19
-- ../go.work --
go 1.19

use (
        ./a
        ./b
)

foo$ go run .
go: no packages loaded from .

foo$ go build .
directory . is contained in a module that is not one of the workspace modules listed in go.work. You can add the module to the workspace using go work use .

[bcmills]

(And the go work use . at the end of that message looks like a typo'd sentence, when in fact that . is part of the suggested command.)

[gopherbot]

Change https://go.dev/cl/418094 mentions this issue: cmd/go: propagate match errors in 'go run'