Following the same idea, should go build ./foo/ fail?

/cc @matloob @bcmills @jayconrod

This doesn't seem like a bug. Why should cmd/go reject these paths?

Arguments to go get and other build commands aren't expected to be valid import paths. We allow file paths, directory paths, local paths (../foo), patterns (with ...), metapackages (cmd, std, all), non-clean import paths and so on. On Windows, paths may also use backslashes.

This is pretty convenient, I think. Changing this would break scripts and automation, too.

@jayconrod you are right, thanks. I was not aware that go get supported patterns, but it is clearly documented. go get golang.org/x/mod/... works as expected, as an example.

I'm not sure what go get ./pkg or go get ... is supposed to do, however.

Out of curiosity I tried, inside a module.

$ go get -v ~/src/go/src/test.local/bar
go get /home/manlio/src/go/src/test.local/bar: malformed module path "/home/manlio/src/go/src/test.local/bar": empty path element

with a little expectation for go get to get the local module (like pip with Python, if I remember correctly).

On the other hand (using the same test.local/bar package)

$ go get -v ../bar
go get ../bar: path /tmp/.tmp/bar is not a package in module rooted at /tmp/.tmp/foo

When outside a module

go get -v ../bar
go: cannot find main module; see 'go help modules'

That is a different error message, compared to the case of getting a remote module. This means that go get does not handle .../bar as a remote import path. But how does go get handle it?

Thanks.

go get takes a set of packages, then updates the modules that provide those packages to the latest version (or any other version named after an @ suffix). The main module can't be updated to a different version, so it usually doesn't make sense to go get packages in the main module unless you're using the -u flag flag (which updates modules that provide dependencies of the named packages).

For go get -v ~/src/go/src/test.local/bar, the error message seems bad. Where is go.mod for that? What's the module path? What's in that directory?

For go get -v ../bar, that message seems correct. When naming a package with a relative path, you can only refer to packages in active modules. So that's either the main module, something in the module cache, or something on the right side of a replace directive.

For go get -v ../bar outside a module, relative paths can't really work since there are no active modules. So that message seems okay, though not great.

For go get -v ~/src/go/src/test.local/bar, the go.mod file inside that directory is

module test.local/bar

go 1.13

Thanks.

Thanks, reproduced that one with 1.14.1.

If it's all right, I'll repurpose this issue for fixing that message specifically. I think the other behaviors and messages are correct.

Change https://golang.org/cl/226857 mentions this issue: cmd/go: report 'go get' errors for absolute paths outside module root