Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: install foo/v2 as binary "foo" #24667

Closed
rsc opened this issue Apr 3, 2018 · 10 comments
Closed

cmd/go: install foo/v2 as binary "foo" #24667

rsc opened this issue Apr 3, 2018 · 10 comments
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Apr 3, 2018

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

@rsc rsc added this to the vgo milestone Apr 3, 2018
@rsc rsc added the NeedsFix The path to resolution is known, but the work has not been done. label Apr 3, 2018
@rsc rsc changed the title vgo: install foo/v2 as binary "foo" x/vgo: install foo/v2 as binary "foo" Apr 3, 2018
@adamdecaf
Copy link
Contributor

Would there be support for installing multiple versions of foo?

@myitcv
Copy link
Member

myitcv commented Apr 3, 2018

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
Copy link
Contributor

@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
Copy link
Member

rasky commented Apr 3, 2018

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
Copy link
Contributor Author

rsc commented Apr 5, 2018

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 rsc closed this as completed Apr 5, 2018
@rsc rsc reopened this Apr 5, 2018
@rsc
Copy link
Contributor Author

rsc commented Apr 5, 2018

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
Copy link
Contributor

mewmew commented May 3, 2018

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.

@rsc rsc modified the milestones: vgo, Go1.11 Jul 12, 2018
@rsc rsc added the modules label Jul 12, 2018
@rsc rsc changed the title x/vgo: install foo/v2 as binary "foo" cmd/go: install foo/v2 as binary "foo" Jul 12, 2018
@bcmills
Copy link
Contributor

bcmills commented Jul 13, 2018

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
Copy link

Azareal commented Jul 16, 2018

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
Copy link
Contributor

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

8 participants