Go: cmd/go: install foo/v2 as binary "foo"

[rsc]

If we're installing a binary with import path blah/blah/foo/v2, we should install it as foo, not v2.

[adamdecaf]

Would there be support for installing multiple versions of foo?

[myitcv]

Would there be support for installing multiple versions of foo?

I am not sure what the target bin directory structure would look like (and therefore what my PATH would need to look like)

Alternatively @adamdecaf would support for go run taking an import path suffice/be better?

[adamdecaf]

@myitcv Not really. I'm thinking more about being able to have a "foo v2" and "foo v3" binary around usable by programs wrapping the binary. No idea what $GOPATH/bin has to look like though.

I understand that the last execution of go install wins that battle now, but if there was an option which allowed versioned binaries at $GOPATH/bin that would be nice. It's probably too big of a task to tackle initially though.

[rasky]

One option would be to install foo.v2 and create a symlink foo -> foo.v2, with the latest go install winning the symlink race, but all versions available using the suffix.

On the other hand, what is the use case for an installable module having a major version number in the vgo world? It looks like the semantic version is used to express API breakage for libraries, so it doesn't look like it's so important for installable modules, nor it does necessarily convey some usable information; so maybe the above suggestion is just over-engineering a non-problem.

[rsc]

Binaries with conflicting names are not a new thing in vgo. You already have the problem with things like

go get rsc.io/toolstash
go get golang.org/x/tools/cmd/toolstash

Fundamentally you can only have one in your $PATH. Sorry.

I believe solving this problem is out of scope for the go command generally. It's certainly out of scope for vgo.

[rsc]

Sorry, I was replying to the earlier comment stream and forgot that was not the original issue. The original issue stands: we need to strip the /v2.

[mewmew]

What if the tool is actually called v2 (or some other vNUM)?

On a related note, how does the Go tool handle internal paths in relation to the GitHub user https://github.com/internal?

The second questions is perhaps less serious, but the first one, I currently can't see how you'd differentiate between a tool actually being called v2 from one of version 2. For say github.com/user/repo/foo/bar/v2, then bar may be a separate tool and not simply version 1 of the same tool as v2.

[bcmills]

What if the tool is actually called v2 (or some other vNUM)?

Don't do that?

But the module path should help to disambiguate, too: perhaps a binary package in subdirectory foo/bar/v2 within a module with module path github.com/user/repo really should be named v2. The ambiguous cases occur when the module path itself ends with /v2 and the package is located at the module root.

[Azareal]

What if the tool is actually called v2 (or some other vNUM)?
One that immediately comes to mind is the V8 Engine (the one in Chrome), if someone does some sort of wrapper for that or something, but that could probably be nested somewhere or the packages could be more descriptively named.

Purely hypothetical example though.

[gopherbot]

Change https://golang.org/cl/128900 mentions this issue: cmd/go: fix install target name for versioned binaries