[speedgoose]

It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy.

Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some dependencies do not resolve anymore.

[mseepgood]

> I'm also unsure of what is going to happen over time as dependencies may be moved or removed

That's what the Go module proxy is for. The authors can move or remove their repositories as much as they want, I as a dependent am not bothered by it. They would have to go through an official vetted process to get it removed from the proxy.

[speedgoose]

Oh I didn’t know that the proxy.golang.org was a thing. That’s good to know.

[aaomidi]

This is why you should vendor your dependencies. They are part of your codebase at that point.

[speedgoose]

I have better things to do though. This feels unnecessary.

[aaomidi]

“go mod vendor”.

That’s it. That’s all you need to do.

[speedgoose]

Oh like this. I’m not sure I would enjoy overloading my git repository and merge requests with the dependencies. I was thinking about having a proxy or forking all the dependencies.

[aaomidi]

The thing is though that those dependencies are part of your code. Seeing how they're changing through PRs and commits is actually a feature IMHO and not a bug.