Go-Package-Store should know how to update itself

[Netherdrake]

It should run go build && go install on itself.

[dmitshur]

A general solution would be to get rid of the -d flag when executing go get -u -d some/package/....

But I'm worried that might install too many unwanted binaries into $GOPATH/bin. Thoughts?

[dmitshur]

By the way, until this issue is closed, updating Go Package Store manually is as easy as:

go get -u github.com/shurcooL/Go-Package-Store

[dmitshur]

I could special-case the Go Package Store import path, and do something differently for it. But I feel that isn't as great as a more general solution.

Perhaps binstale can be used for a more general solution. Its functionality can be used to determine which Go binaries you have installed, and whether something package you're installing contains binaries that would need to be updated.

Or maybe it can be a separate tab in Go Package Store. The current page can be considered a page for source code updates. The other tab can be a page for binary updates.

Maybe it's better to keep the two more connected; updating the source of a binary perhaps should update the binary too.

Thoughts on this are welcome.

[dmitshur]

But I'm worried that might install too many unwanted binaries into $GOPATH/bin. Thoughts?

Oooh, I have a great idea!

I could do the following. When updating repos that contain commands (Go packages with name "main"), I can check if such a binary exists in $GOPATH/bin already. If so, I can go install that command.

That way, it would update existing binaries in $GOPATH/bin but not install new, unwanted ones.

The only downside is that it's possible to mistakenly overwrite the wrong binary, in case of a command naming ambiguity. For example, imagine you've installed a command foo via go get -u example.com/user/foo and later update another repo example.com/some/repo/... that happens to contain example.com/some/repo/something/no/one/uses/called/foo and that other binary foo replaces your original foo.

[dmitshur]

The only downside is that it's possible to mistakenly overwrite the wrong binary, in case of a command naming ambiguity.

It might be possible to resolve that ambiguity by using debug/gosym to extract the exact import path from binary. See shurcooL/binstale#6 for details.

This needs to be investigated and confirmed, but it's a great lead! Thanks @FiloSottile for the original idea!

[dmitshur]

This is a feature I'd like to implement someday, and I'm using this issue to track the progress towards that. It's not done yet. I'd like to keep it open until it's done, if that's okay with you @Netherdrake.