Use golang 1.17

[rumpl]

What I did

Updated golang version to 1.17

Updated some dependencies too, left untouched: containerd, buildx and buildkit, the build fails with buildkit 0.9.1, I would need more time to see what is going on there

Output of check-dependencies after this change:

❯ make check-dependencies     
go list -u -m -f '{{if not .Indirect}}{{if .Update}}{{.}}{{end}}{{end}}' all
github.com/containerd/containerd v1.5.5 [v1.5.7]
github.com/docker/buildx v0.5.2-0.20210422185057-908a856079fc [v0.6.3]
github.com/moby/buildkit v0.8.2-0.20210401015549-df49b648c8bf [v0.9.1]

(not mandatory) A picture of a cute animal, if possible in relation with what you did

[ulyssessouza]

LGTM

[thaJeztah]

Looks like we're also updating various dependencies here; were these needed for Go 1.17? (otherwise it's good practice to do this separately).

[rumpl]

Not needed, thought I could do both at once with a nice comment on the PR, can separate if needed

[thaJeztah]

This may also print a warning that Go 1.17 is the minimum version supported; probably ok (not sure if anything is using the modules from this repository as a dependency), but it's common to support at least "latest" + "latest-1"

[rumpl]

Maybe we should put a warning in the README, tell people not to depend on this cli, or just move everything to internal

[thaJeztah]

Perhaps just a warning would be ok. internal always feels a bit like a "big hammer" to me (we forbid you to use this code!)

That said; trying to only export things that are relatively / considered stable is good practice (also helps the mental overhead to know ("this function/const/variable is not exported, so I can change this without side-effects". My IDE also is better at pointing me at unused functions if they're not exported)

[thaJeztah]

Do we know if there's any "overrides" in the list of // indirect dependencies? Overall I think the go1.17 format makes sense for "indirect dependencies that we didn't manage", but if there's any // indirect that was explicitly added to the list to force a "newer version than go.mod resolved automatically", it may be good to put those in the first list.

That way it's clear what versions are "managed" in this go.mod (first block), and what versions are set "automatically" (so can be "ignored" when reading the go.mod)

Also see moby/buildkit#2331 (comment)

[rumpl]

I don't think we manually override any // indirect dependencies, I didn't even know you could do that, I tend to think of the go.mod file as a lockfile I shouldn't update manually but only use go tool (unless you want to change the go version... go modules...)

It's really optimistic in my opinion to update the go.mod file like that, what will happen when go 1.18 or 19 or 20 comes and they decide they want to change the way they write this mod file, like what they did with the 1.17 version

[thaJeztah]

I don't think we manually override any // indirect dependencies, I didn't even know you could do that

Yes, so you can use it in situations where you know an indirect dependency should be on a newer version than what go.mod automatically finds. In that case, you can add a // indirect with the version you want it to be on. The // indirect will automatically disappear once any other dependency requires a newer (or same) version of that dependency.

I know we had a couple of those in buildkit, but if that's not the case here, then no worries

It's really optimistic in my opinion to update the go.mod file like that, what will happen when go 1.18 or 19 or 20 comes and they decide they want to change the way they write this mod file, like what they did with the 1.17 version

I think even for Go 1.17, the split format is still optional (you can give options to split or not), but time will tell of course (it should still be possible to leave comments after the // indirect, e.g.

github.com/foo/bar     // indirect // using a newer version to address #123454

[rumpl]

Closing this one, I'll open two PRs one for golang and one for updating deps