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

Allow updating of stale packages #9

Open
deepakjois opened this issue Sep 15, 2016 · 6 comments
Open

Allow updating of stale packages #9

deepakjois opened this issue Sep 15, 2016 · 6 comments
Labels

Comments

@deepakjois
Copy link

I just tried binstale, and the next thing I wanted was to update all the stale binaries. Maybe you could provide a flag (-u perhaps…) which can update the stale binaries, by invoking go get -u

@dmitshur
Copy link
Member

dmitshur commented Sep 15, 2016

This is a reasonable request, but it's going to be a little tricky at this time.

First, there might be ambiguities, where it's unclear if a binary named foo is coming from import path bar/cmd/foo or baz/cmd/foo. Here's a real world example:

go-diff
    STALE: github.com/daviddengcn/go-diff (build ID mismatch)
    STALE: sourcegraph.com/sourcegraph/go-diff/cmd/go-diff (build ID mismatch)

That's really the main concern right now. I have an idea for how to potentially get around this. When/if #6 is resolved, this might become more viable. I'll leave this open and add a "thinking" label for now.

Meanwhile, someone on reddit shared the following unix-y way you can achieve this goal:

binstale | grep 'stale:' | cut -d " " -f2 | xargs go get -u

You can try that, maybe even make an alias for it if you do it often.

@christophberger
Copy link

Could the update option simply skip all ambiguous cases?

@dmitshur
Copy link
Member

@christophberger Yes, that's a possible workaround.

However, instead of investing into workarounds, I think I'd rather resolve #6 and this can be solved more properly. Until then, the grep-cut-xargs solution should be okay.

@christophberger
Copy link

Good point. Waiting for #6... :)

@christophberger
Copy link

I discovered that Go binaries still include the source path that they were compiled from. This Reddit comment pointed me to this shell function which uses go tool objdump and extracts the source path from the objdump output line that starts with TEXT main.main.

This looks like a sure-fire way of unambiguously determining the source project of a binary.

@dmitshur
Copy link
Member

@christophberger Thanks for sharing the info. I know they currently do.

I already have a prototype of that working at https://godoc.org/github.com/shurcooL/play/200/cmd/importpathof (source code).

It's been on my plans/TODO to take advantage of that:

  • binstale: Use importpathof and post/ask about that on Go forums.

However, using that information would mean a massive re-architecture of a huge portion of binstale code. Before doing that, I wanted to ask on the Go mailing list for the opinion of the Go team whether or not they expect such import path information is expected to always continue to be there in the future versions of Go, or if they think it's temporary and I should not rely on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants