-
Notifications
You must be signed in to change notification settings - Fork 5
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
Some edge cases not handled #3
Comments
Thanks for trying out the tool and reporting bugs! I appreciate it. I will try to fix some of them in the upcoming days and post updates in this issue |
Thanks! If it helps, here are links to the source code of the edge cases that were problematic:
|
Thanks for sharing the exact URLs, those are definitely helpful 👍
|
So I am now running on Go 1.17.5:
But it appears that I built genqlient from source using Go 1.17.1:
Which is odd, because the utilities that succeeded give different results:
|
Which references: golang/go#49228:
|
Thanks for providing all that information and finding golang/go#49228. I have trouble understanding how you got to have When I build a package from source, I see the 19:40 $ go version -m genqlient
genqlient: go1.17
path github.com/Khan/genqlient
mod github.com/Khan/genqlient (devel)
dep github.com/agnivade/levenshtein v1.1.0 h1:n6qGwyHG61v3ABce1rPVZklEYRT8NFpCMrpZdBUbYGM=
dep github.com/alexflint/go-arg v1.4.2 h1:lDWZAXxpAnZUq4qwb86p/3rIJJ2Li81EoMbTMujhVa0=
dep github.com/alexflint/go-scalar v1.0.0 h1:NGupf1XV/Xb04wXskDFzS0KWOLH632W/EO4fAFi+A70=
dep github.com/vektah/gqlparser/v2 v2.3.1 h1:blIC0fCxGIr9pVjsc+BVI8XjYUtc2nCFRfnmP7FuFMk=
dep golang.org/x/mod v0.4.2 h1:Gz96sIWK3OalVv/I/qNygP42zyoKp3xptRVCWRFEBvo=
dep golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e h1:WUoyKPm6nCo1BnNUvPGnFG3T5DUVem42yDJZZ4CNxMA=
dep golang.org/x/tools v0.1.7 h1:6j8CgantCy3yc8JGBqkDLMKWqZ0RDU2g1HVgacojGWQ=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
dep gopkg.in/yaml.v2 v2.4.0 h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY= Anyway, I believe I will change the code to skip the update attempt if:
In either case the binary will be mentioned in the summary just so it was acknowledged and the engineer can act on it if they want to fix/upgrade the package manually. Let me know if you have a clue how you could end up with I would also appreciate it if you pasted the output of |
|
So I can reliably recreate the "command-line-path" situation even with Go 1.17.5:
I'm not sure if this is because the |
When I was looking into this, I found a similar tool nao1215/gup. When they detect |
Thanks for the replies and for looking into the problem again! The output of -github.com/googleapis/gnostic
+github.com/google/gnostic Thank you for sharing the instructions how to get build a binary with a Also, thank you for finding https://github.com/nao1215/gup. Too bad I have not seen it before starting this project, seems like duplicate effort. I will describe that alternative tool in the README. Looks like I have all the information to handle the edge cases you presented in this issue. None of them will be auto-upgradable, unfortunately, but |
Thanks very much! BTW, There was also an older tool shurcooL/binstale from before modules that seems to not work so great anymore. |
Detect when a binary was built or installed from source (either using `go build main.go` on a Go file specifically, or using `go install` in the cloned repository) and skip updating such binaries. Binaries installed from source (`go install` in the cloned repository) may have been modified by the engineers prior to being built, which means their version may not be the same as the latest versions in the upstream repositories. On top of that, binaries built from a Go file directly (`go build main.go`) have `command-line-arguments` set as their `path` in `go version -m`. This makes it impossible to see where a binary came from.` In both cases, a message is logged to the console and the command still passes. Encountering such binaries does not cause `go-global-update` to fail. Closes #3
Detect when a binary was built or installed from source (either using `go build main.go` on a Go file specifically, or using `go install` in the cloned repository) and skip updating such binaries. Binaries installed from source (`go install` in the cloned repository) may have been modified by the engineers prior to being built, which means their version may not be the same as the latest versions in the upstream repositories. On top of that, binaries built from a Go file directly (`go build main.go`) have `command-line-arguments` set as their `path` in `go version -m`. This makes it impossible to see where a binary came from.` In both cases, a message is logged to the console and the command still passes. Encountering such binaries does not cause `go-global-update` to fail. Closes #3
I have just released v0.1.1 which should handle some of the edge cases more gracefully. I have also created #4 to add more information about other edge cases you found to provide more context about the problems. Let me know if you think there is something else we can do to make using this tool easier Thanks once again for reporting these problems! I appreciate it. Feel free to create other issues whenever you find something that can be improved |
For anyone landing here, I was getting the following error on every binary:
I ran it with TL;DR: you need |
Hi! This worked brilliantly for most things! Thank you so much! However, there were a few things that did not get handled well.
The text was updated successfully, but these errors were encountered: