Let some people know they can try out newer versions, if we know they aren't bad!

DarthHater commented 3 years ago

It dawned on me that because go list -m -json -u all let's us know the newest version of something, we can run that version past OSS Index and see if it's vulnerable or not. If it's not, let's suggest someone update to it!

This pull request makes the following changes:

way too many to count right now, putting this up to start getting feedback!

Of note, this is slower, but it's because go list -m -json -u all is making requests to I assume pkg.go.dev to see what the newest version of a package is

TODO:

go through and fix busted tests, add good new ones
modify how we pass things around such that we know if someone used dep or go mod, so we can give them the right instructions on how to fix things
suggest a go get -u command to users if the dependency is in the go.mod file, and then the replace if the dependency is not in their go.mod file?

This builds the path towards a nancy solve command where we can go ok, you want us to take care of this? We will give it a shot! That command can work with both ossindex and iq, because we should get similar data from IQ, knowing what the recommended version of something is.

cc @bhamail / @DarthHater

DarthHater commented 3 years ago

Seems mostly sane to me. Project=Dep and Coordinate stuff gets confusing, but I don't see a clearer path. "Naming" (pronounce like Seinfeld "Newman").

For later discussion (version 2?): When we find a "clean" newer version, is a "replace" directive the best solution to suggest? If we could determine if the dependency is non-transitive (is direct - not indirect), then maybe suggesting a go get -u mydep@v command is better? Probably a lot more trouble, but wanted to ask. In my mind, the problem with adding replace directives is they are a form of technical debt - ideally, you always prefer upgrading to new versions of deps instead. With replace directives, you need to go back "someday" and determine if the directive can be removed in favor of a newer dependency version.

I absolutely agree with you. What I was THINKING is we can parse go.mod to see if the dependency is in there, and if it is, we can suggest go get -u <dependency>, and if not, suggest the replace. It'd be nice if the go API had the ability to let us see what brought something in (which is slightly possible with go mod graph but it's not maybe the cleanest way of getting things)

What do you think about changing Project to Dependency because that might be clearer?