Recent searches
Search options
I'm increasingly starting to dislike the "simplicity" of #golang's "go mod" system. The lack of something resembling an idiomatic way to manage dev dependencies means contributing to a Go project often entails downloading several binaries (golangci-lint, gci, gofumpt, whatever) out of band, which versions must match those in CI. Those should just be dependencies of the project for fuck's sake! And managed as any other dependency. Any tool (which isn't Docker) that does this well for Go?
@anderseknert I've come to like the "tools.go pattern" for this: https://www.jvt.me/posts/2022/06/15/go-tools-dependency-management/
@anderseknert There's also https://go.googlesource.com/proposal/+/54d6775ff71ccbc00c276db2a4e4841d67011cf4/design/48429-go-tool-modules.md which attempts to formalize this and make it a proper part of the tool stack (no pun intended...). Like everything else in Go-land, it seems this won't become part of the standardized stuff with proper support until at least five years after folks start complaining about it...
@tomasaschan Thanks for both pointers! I'll have to try that tools.go method to see how it works in practice.
Also, LOL, as I just before you posted referred to Jamie as *the* "dependency guy" in the other thread https://elk.zone/hachyderm.io/@anderseknert/113191706986003922
Ping @charlieegan3 — we should look into this for Regal
@anderseknert @charlieegan3 @www.jvt.me @arichtman Haha, I read that but didn't even realize it was the author of the post I linked. I just searched for something like "go tools.go" and took the first hit I recognized as one I read when learning how to use the pattern 
The proposal had a few nice descriptions of requirements to make it work, too, so I recommend giving that a read too just to avoid some common mistakes that aren't super clearly pointed out in the blog post.
Yeah I'm very much looking forward to // tool landing as that'll push more folks to using a tools.go style approach.
I'm seeing some folks who'll use a tools.go in a separate Go module so then it doesn't impact the top-level dependency tree, on top of Go' s inbuilt module graph pruning
Also as much as I recommend tools.go, there's still some things it can be awkward with ie golangci-lint tracked as a source dependency can lead to issues (dependency version clashes, Go version incompatibility), as well as it not being the recommended use case
