We have lots of repos with go code. Go modules has certainly been a huge improvement in how dependancies are handled. But it seems like the tooling can be improved.
For example, I have a simple question (on a frequent basis). Which of the dependancies I have listed in the go.mod file for my app should be updated because a new version exists?
Which much digging - one can find this in the module documentation:
go list -u -m all
Actually, I first tried it without “all” but that returns nothing - as all of my code for our services is in a few different directories on level below. So I add the all option - and man a lot of stuff gets spit out. Not just the info for what is in go.mod - but for their dependancies as well. Useful information to be sure - but it is not making it easy to determine which dependancies I should upgrade.
I can’t even filter the data from the tool itself. (Can go templates ever support ways to filter data? Or how about a continue statement?)
Good news is with the -json I can spit it out and use something else. So with a little pouring over how the hell jq works I finally got something like this:
go list -u -m -json all | jq -r '. | select(.Update) | select(.Indirect == null) | .Path + "@" + .Version + " => " + .Path + "@" + .Update.Version'
This command one obviously needs put behind an alias or a script - will tell me exactly which modules in my go.mod file are out of data. What version it is currently at and what one I should update to.
Whew! I’m actually hoping I’ve missed some much simpler way to answer this basic question. I’d love to hear of a better way to do this. Otherwise, can I humbly ask the tooling support for supporting modules in real life be improved?
Ray
P.S. Actually, I would love to have much more. Like a way to know if certain versions of common libraries have security issues. Also, it is SOOOOOO painful when someone moves a library. Like when Sirupsen/logrus moved to sirupsen/logrus or garyburd/redigo moved to gomodule/redigo.