Update go dependencies

[jim]

Description

It seems that in the switch from dep to go mod a bunch of our dependencies were downgraded, probably due to how go mod uses the minimum version that will satisfy requirements for indirect dependencies.

This PR updates most of our dependencies to the latest version.

Reviewer Notes

You can run the script to update dependencies locally like so:

$ make go_deps_update

I noticed that go vet sometimes alters go.mod. I'm not sure why.

Code Review Verification Steps

• Request review from a member of a different team.

References

• PR where we switched to go mod

[pjdufour-truss]

Since we don't have a tagged release on github.com/trussworks/pdfcpu for our afero work, you need to run the following to tag the latest commit on the afero branch.

go get github.com/trussworks/pdfcpu@afero

[chrisgilmerproj]

Would be nice to also have an example of getting the dependency @master, which I think is the right syntax. I think a lot of our deps we want at the master version.

[chrisgilmerproj]

I'd love one more thing added to the README. But I'm not going to block. Thanks for doing this.

[pjdufour-truss]

This PR is reverts cobra, viper, and pflag. Since we want master branch for those, so this is still blocked.

[ralren]

Looks good. All the different apps ran fine.

[jim]

@pjdufour-truss Can you take a look at this again when you have a minute? I think we're in good shape.

We might need to tag our fork pdfcpu to a version as there isn't a nice way to pin to a non-master branch and if possible I'd like to avoid special casing for a single dependency. Added code to handle this case.

[pjdufour-truss]

Awesome work. However, it looks like go.mod is still out of sync. Could you squash and rebase from master and then roll forward from a clean go.mod?

For example, cobra/viper/pflag should be tracking master instead are on tagged versions. Should the custom branches logic preceed the semver logic? Should we hard-code more versions in the program. Not to bloat this more, but we could have a simple requirements file that includes branch overrides.

[pjdufour-truss]

Could you also look into using https://godoc.org/os/exec#CommandContext and maybe setting a default timeout for each package with a few retries? One of the go get commands stalled on me.

[jim]

@pjdufour-truss I didn't add any retries yet, but I did add a timeout as you suggested. If we find ourselves retrying a lot we can go ahead and put that in.

[pjdufour-truss]

Can we remove gosec (or comment it out with TODO) since it wasn't working with modules yet?

[pjdufour-truss]

It looks like the newest version of pop changed UUID libraries. Can we confirm that's not an issue? gobuffalo/pop#348

[jim]

@pjdufour-truss

It looks like the newest version of pop changed UUID libraries. Can we confirm that's not an issue? gobuffalo/pop#348

It looks like we're already on github.com/gofrs/uuid v3.2.0+incompatible on master. This is just a different fork of the same original codebase with only minimal API changes compared to the gobuffalo one. The app and tests run so I think we're OK here.

Can we remove gosec (or comment it out with TODO) since it wasn't working with modules yet?

Sure thing. I'll make that change. Thanks for mentioning it.

Requested changes have been made.