if an argument refers to non-main packages (perhaps just a module path that's not a package, as above), that argument is used in version selection.

What if an extra argument results in no changes in version selection for the main package to be built? For example, go install example.com/cmd@latest github.com/user/totally-unrelated-module@v0.2.0 should error instead of silently doing the same as go install example.com/cmd@latest, I imagine.

What if an extra argument results in no changes in version selection for the main package to be built?

It seems well-formed, so I think that should be allowed, even if it isn't necessarily useful. It might make it easier to install a bunch of commands from different modules:

cmds=(example.com/m1/cmd example.com/m2/cmd)
for cmd in ${cmds[@]}; do
  go install $cmd@latest golang.org/x/tools@v0.1.0
done

The extra module dependency would still influence the go version -m output, though that's probably not important here.

My wording of "results in no changes in version selection" was also poor. What if $cmd@latest already uses an x/tools version newer than v0.1.0? We don't want the command to start erroring simply because the x/tools argument results in no dependency version upgrades.

I think what I meant is: reject arguments which can't possibly affect version selection for the main module, such as modules which are not in the module graph of the main module.

That said, I think you're right that it seems too restrictive. It could also cause problems if $cmd@latest has x/tools in the module graph today, but a new version comes out today which no longer has x/tools in the module graph. We don't want go install to start failing even though the build would still work.

Some comments from the golang-tools meeting earlier today:

• The story about upgrading past a security vulnerability when building a command doesn't resonate that well. Command authors should be responsible for upgrading quickly; that responsibility shouldn't be on their users.
• A command line like go install example.com/cmd@latest golang.org/x/tools@v0.1.0 is a bit confusing, since golang.org/x/tools isn't actually being installed or even built.

I also worry about package/module ambiguity. The arguments to go get and go install are packages, but go get also allows arguments that are module paths.

Users often try to upgrade dependencies by passing module paths to go get instead of package paths, and that actually mostly works as long as they run something afterward (such as go mod tidy) to populate checksums for transitive dependenices.

But if someone tries to do that with go install, and the module they're trying to upgrade happens to contain another binary at the module root, then the command could inadvertently run afoul of the restriction that main packages come from only one module, and I worry that the resulting error messages would be too confusing.

The story about upgrading past a security vulnerability when building a command doesn't resonate that well. Command authors should be responsible for upgrading quickly; that responsibility shouldn't be on their users.

Consider also that it'd make it possible for users to make a command vulnerable (accidentally or by being tricked).

Suppose that example.com/lib@v1.2.0 and example.com/lib@v1.3.0 have a vulnerability which is fixed in v1.2.1 and v1.3.1 patch releases. If example.org/cmd@v1.0.1 uses lib@v1.2.1, then go install example.org/cmd@v1.0.1 example.com/lib@v1.3.0 is problematic despite looking innocuous.

The same problem can happen when authors perform version selection, but this is to support that the responsibility of selecting versions is better suited for authors (fewer, goes through code review, vulnerability databases, etc.) than users (many, can be copy-pasted from anywhere).

I was pushing for this but based on the discussion it sounds like we should probably not do it.

Withdrawing this issue, reflecting discussion above.