In module mode, non-main packages lack an install target, and go install for such packages is equivalent to go build (compare #46911).
As such, a call to go install with a pattern containing only non-main packages is at best confusing: at best, the user has conflated go install with go build, and at worst, they are trying to install a binary but have named a corresponding library instead.
The latter case crops up surprisingly frequently. For example, the library golang.org/x/tools/imports is easily confused with the executable golang.org/x/tools/cmd/goimports, and the library github.com/gobuffalo/buffalo is easily confused with the executable github.com/gobuffalo/buffalo/buffalo.
I don't think we need to actually remove the ability to call go install on a non-main package, but we should at least log something to clear up the user's likely confusion.
This issue is a companion to proposal #41696, brought to my attention via https://stackoverflow.com/q/64462190.
In module mode, non-
main
packages lack an install target, andgo install
for such packages is equivalent togo build
(compare #46911).As such, a call to
go install
with a pattern containing only non-main
packages is at best confusing: at best, the user has conflatedgo install
withgo build
, and at worst, they are trying to install a binary but have named a corresponding library instead.The latter case crops up surprisingly frequently. For example, the library
golang.org/x/tools/imports
is easily confused with the executablegolang.org/x/tools/cmd/goimports
, and the librarygithub.com/gobuffalo/buffalo
is easily confused with the executablegithub.com/gobuffalo/buffalo/buffalo
.I don't think we need to actually remove the ability to call
go install
on a non-main
package, but we should at least log something to clear up the user's likely confusion.CC @jayconrod @matloob