search

shurcooL / Go-Package-Store

An app that displays updates for the Go packages in your GOPATH.
MIT License
899 stars 29 forks source link

Go-Package-Store should know how to update itself #34

Open Netherdrake opened 9 years ago

Netherdrake commented 9 years ago

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

dmitshur commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/shurcooL/binstale/issues/6 for details.

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

dmitshur commented 7 years ago

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.