"go install": no warning/error when binaries conflict

[tom....@centralway.com]

Consider a package with multiple binaries with the same name, "cmd" in this case:

pkg1/cmd/main.go:

package main; import "fmt"; func main() { fmt.Println("pkg1") }

pkg2/cmd/main.go:

package main; import "fmt"; func main() { fmt.Println("pkg2") }

When running

  $ go install ./...

I would expect to get an error (or at least a warning) that the binaries conflict: there can only be one file called "cmd" in $GOBIN. However, "go install ./..." silently ignores the duplicate. One of the binaries "wins" and the other is lost.

For reference, the "cp" command in GNU Coreutils prints a warning when this occurs:

  $ cp pkg1/cmd/main.go pkg2/cmd/main.go .

  cp: will not overwrite just-created './main.go' with 'pkg2/cmd/main.go'

Would the Go team be interested in a fix for this?

Cheers,

Tom

This message is for the attention of the intended recipient(s) only. It may contain confidential, proprietary and/or legally privileged information. Use, disclosure and/or retransmission of information contained in this email may be prohibited. If you are not an intended recipient, you are kindly asked to notify the sender immediately (by reply e-mail) and to permanently delete this message. Thank you.

[Ian Lance Taylor]

On Tue, Jul 18, 2017 at 7:27 AM, <tom....@centralway.com> wrote:
>
> Consider a package with multiple binaries with the same name, "cmd" in this
> case:
>
> pkg1/cmd/main.go:
> package main; import "fmt"; func main() { fmt.Println("pkg1") }
>
> pkg2/cmd/main.go:
> package main; import "fmt"; func main() { fmt.Println("pkg2") }
>
> When running
> $ go install ./...
> I would expect to get an error (or at least a warning) that the binaries
> conflict: there can only be one file called "cmd" in $GOBIN. However, "go
> install ./..." silently ignores the duplicate. One of the binaries "wins"
> and the other is lost.
>
> For reference, the "cp" command in GNU Coreutils prints a warning when this
> occurs:
> $ cp pkg1/cmd/main.go pkg2/cmd/main.go .
> cp: will not overwrite just-created './main.go' with 'pkg2/cmd/main.go'
>
> Would the Go team be interested in a fix for this?

Sure. Thanks.

Ian

[Paul Jolly]

Random drive-by comment...

Another solution would be to have go install put its results in subdirectories beneath $GOPATH/bin corresponding to source packages. 

For example, considering the program goimports:

$ go get golang.org/x/tools/cmd/goimports

$ go list -f '{{.Target}}' golang.org/x/tools/cmd/goimports

/path/to/gopath/bin/golang.org/x/tools/cmd/goimports/goimports

$ export PATH="$GOPATH/bin/golang.org/x/tools/cmd/goimports:$PATH"

$ which goimports

/path/to/gopath/bin/golang.org/x/tools/cmd/goimports/goimports

Would require more specific updating of PATH in environments etc which has pros and cons. But then name conflicts disappear totally.

To preserve backwards compatibility go install could put one copy in $GOPATH/bin (current behaviour, susceptible to conflicts/overwriting) and a second copy in a package subdirectory. Clearly there would be a cost in storage terms... but that cost is probably negligible these days?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.