cmd/go: allow local imports in non-local packages

[DeedleFake]

Consider the following file structure:

$GOPATH/src/example/example.go (Imports "./other")
$GOPATH/src/example/other/other.go

Currently, if you run go build example, the command will fail with local import "./other" in non-local package. In many cases, this is not a problem; for example, in this case, you could just use import "example/other" instead.

However, this quickly becomes a problem when dealing with GitHub forks. For example, let's say that the example package is a command that I've pushed to GitHub. In this case, the import line would be import "github.com/DeedleFake/example". Someone else decides that they want to contribute, so they fork the repo. Two repos now exist: github.com/DeedleFake/example, and github.com/someone/example.

The problem is that they want to make a change to other. In order to do so, they must modify every instance of the import line in example in order to build their modified version, but they have to remember to change them all back before submitting a pull request. This is tedious and error prone. In the worst case, they miss one or two of the imports and github.com/someone/example winds up importing both github.com/someone/example/other and github.com/DeedleFake/example/other.

So, I propose that relative imports be allowed inside of a GOPATH. Especially with internal packages incentifying people to split their code into multiple sub-packages, it just seems to me like it would make sense.

[minux]

relative imports has been proposed and rejected
numerous times in the past.

please see #3515 (comment)
for explanation why it's not supported.

[DeedleFake]

I can see the argument. Given those reasons, how about this change: Only allow relative imports of internal packages.

In other words, this would be allowed:

$GOROOT/src/example/example.go (Imports "./internal/other")
$GOROOT/src/example/internal/other/other.go

Since internal packages only make sense in the context of packages that import them, I don't think this change would be a problem.