Change https://golang.org/cl/208258 mentions this issue: cmd/godoc: don't execute go list -m all when GOMOD is /dev/null

The distinction between the two is intentional. Per https://golang.org/cmd/go/#hdr-Package_lists_and_patterns:

When using modules, "all" expands to all packages in the main module and their dependencies, including dependencies needed by tests of any of those.

In contrast, ... matches all packages found in all active modules, regardless of whether those packages are dependencies of the main module, so it is somewhat more coherent without a “main module”.

Hmm, reading this more closely, I see that you're talking about module patterns rather than package patterns.

The package pattern ... makes sense without a main module, but the module pattern probably does not. We should probably reject wildcard arguments to go list -m uniformly when there is no main module.

Yes, I am talking about listing modules specifically (the -m flag), not packages.

Would you mind elaborating on why go list -m all intentionally reports an error when GOMOD is /dev/null instead of producing empty output and a warning, as before? What's the motivation for making that change?

I'm noticing that doing go list -m and gotip list -m do not produce an error, despite there not being a main module:

# ... same setup as above
$ go list -m
command-line-arguments
$ echo $?
0
$ gotip list -m
command-line-arguments
$ echo $?
0

I'm asking because I'd like to understand this better. Thank you.

The main issue for this is #32027.

To summarize, a command run in module mode outside a module completes slowly when it needs to resolve a package path to a module, since it needs to find the latest version of that module. The command also isn't reproducible, since it may find a different version of the module every time. It's not a good user experience, especially for new users trying out modules by setting GO111MODULE=on globally.

A few different remedies were proposed in #32027. The one we went with was simply to make it an error to resolve an import path to a module. It's still possible to list or build packages in std and packages specified as sources on the command line, as long as they don't depend on anything outside std. go get also continues to work as it does in 1.13.

go list -m is somewhat useful outside of a module because it determines visibility rules for file arguments.

If I'm in module mode and I'm about to go build some_file.go, I know that that file can import $(go list -m)/internal, as well as the internal packages of any prefix of $(go list -m), and in that case I don't really need to care whether there is an actual main module or not.

Change https://golang.org/cl/208222 mentions this issue: cmd/go: report an error for 'go list -m ...' outside a module