When file.go imports a remote package,

cd /abs/path/to
go build /abs/path/to/file.go

fails with:

file.go:3:8: no required module provides package golang.org/x/term: go.mod file not found in current directory or any parent directory; see 'go help modules'

If I add a go.mod file in /abs/path/to directory, the output is:

file.go:3:8: no required module provides package golang.org/x/term; to add it:
	go get golang.org/x/term

If go build is run from a different directory, the /abs/path/to/go.mod file is not recognized. Instead the go tool recognizes the go.mod file in the current directory.

If this is the intended behavior, it should be documented.

@bcmills do you think this is a possible issue for cmd/go implementation?

go run /abs/path/to/file.go

also fail with the same error

file.go:3:8: no required module provides package golang.org/x/term; to add it:
	go get golang.org/x/term

But I think the error message is confusing, since in this case go get will probably fail or, worse, update the wrong go.mod file.

In this case cmd/go should either report an error like

file.go:3:8: package golang.org/x/term is not accessible`

or it should synthesize a go.mod file and do the equivalent of go mod tidy.

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

... When the go command is run, it looks in the current directory and then successive parent directories to find the go.mod marking the root of the main (current) module.

The suggested command is the correct one for the previous one (go run /abs/path) to succeed (update to main module (see prev section) to include the dependency).
I think the suggested error message is even more opaque.
Though this message may change for #44961

synthesized module with dependencies for run is #42088

There are two problems:

1. The documentation says the command is applied to a single synthesized package made up of exactly those files.
   One interpretation is that the go.mod file is not included.
2. It is possible to run go run /abs/path/to/file.go from a directory different from the one containing file.go.
   The same with go build.

Thanks.

I don't see why 2 is a problem, a package is synthesized and run in the context of the current module, and it's an error if the current/main module doesn't provide all the necessary dependencies

IMHO, 2 is a problem for the same reason why go get pkg@version must ignore any go.mod in the current directory or parent directories.

go get pkg@version is the command for updating the current module. Are you thinking of go install pkg@version?
If so those are separate issues, run: #42088 build: 44469

Yes, I was thinking of go install pkg@version. To be more precise, about:

- No module is considered the "main" module. If the module containing
packages named on the command line has a go.mod file, it must not contain
directives (replace and exclude) that would cause it to be interpreted
differently than if it were the main module. The module must not require
a higher version of itself.

I think that something similar should also apply to a synthesized package.

The main problem with a synthesized package is that it currently uses the go.mod reachable from the current directory, so the behavior depends from the directory where the go command is invoked.

Thanks.

Reading the source code of cmd/go, I noted that the documentation does not report that the cgo build constraint is not ignored for synthesized packages

Another possible confusing error. When a non existing .go absolute file is specified, cmd/go reports a different error:

go run /abs/path/to/nofile.go

go: go.mod file not found in current directory or any parent directory; see 'go help modules'

The main problem with a synthesized package is that it currently uses the go.mod reachable from the current directory, so the behavior depends from the directory where the go command is invoked.

The behavior of the go command always depends on the directory where it is invoked. That property is not specific to synthesized packages — for example, it also applies to packages specified as (absolute) filesystem directory paths.

I have noted another unusual behavior with synthesized modules.

From inside the $GOPATH/src/github.com/perillo directory:
GOPATH= go list ./date
reports
main module (synthesized) does not contain package synthesized/src/go/src/github.com/perillo/date

It is the same with:
GOPATH= go list $GOPATH/src/github.com/perillo/date

Sorry, forget the last comment. I had a go.mod file in my HOME directory with module path synthesized.