cmd/go: inconsistent handling of package main importing another package main

[masiulaniec]

The spec seems to allow package main to import another package main under another name.
However, the experience with the go tool is inconsistent:

% cd $GOPATH/src/foo
% cat a/a.go
package main

import _ "foo/b"

func init() { println("init: a") }
func main() {}
% cat b/b.go
package main

func init() { println("init: b") }
func main() {}
% rm -f $GOPATH/bin/a
% rm -f $GOPATH/bin/b
% go install ./a
% touch a/a.go
% go install ./a
# foo/a
a/a.go:3: can't find import: "foo/b"
% 

My setup:

% go env
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread -fno-common"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/p/go"
GOROOT="/usr/local/Cellar/go/1.0.3"
GOTOOLDIR="/usr/local/Cellar/go/1.0.3/pkg/tool/darwin_amd64"
CGO_ENABLED="1"
%

[adg]

Comment 1:

The go tool assumes that a package main is an executable, and this is by design. The use
of "package main" is a signal to the go tool that you want to compile a command, not a
package object.
The spec allows importing another package main to allow for testing of package main. For
instance:
$ cat main.go 
package main
import "fmt"
func Hello() string {
    return "Hi"
}
func main() {
    fmt.Println(Hello())
}
$ cat main_test.go 
package main
import "testing"
func TestHello(t *testing.T) {
    want := "Hi"
    if got := Hello(); got != want {
        t.Errorf("Hello() = %q, want %q", got, want)
    }
}
Behind the scenes, when you run "go test", a new main package is constructed that
imports the package main that is under test.

Status changed to WorkingAsIntended.

[masiulaniec]

Comment 2:

Okay, so maybe at the very least the go tool should reject such programs consistently. 
This scenario:
% go install ./a
% touch a/a.go
% go install ./a
# foo/a
a/a.go:3: can't find import: "foo/b"
% 
is surprising. The go tool should have either errored out on the first run, or succeed
on both; it should do something consistent. It feels buggy that a mere touch breaks the
build.

[davecheney]

Comment 3:

I believe this is related to this issue,
https://golang.org/issue/3417.

[masiulaniec]

Comment 4:

The WorkingAsIntended label seems invalid.

[adg]

Comment 5:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

[rsc]

Comment 6:

Labels changed: added go1.2.

[rsc]

Comment 7:

Labels changed: added feature.

[robpike]

Comment 8:

Status changed to Duplicate.

Merged into issue #4210.