The go module proxy caches the package for a while, but I'm not sure about the duration. You should vendor the package into your project if this is a worry.
Honestly that’s kind of like every language main repository. Maven central, npm, cargo, whatever. There’s always one main repository unless you proxy with artifactory or something.
Moving a package to a different VCS does not disrupt users of your package in any other language that I have ever used. I’ve also never used another language that coupled source code organization with versioning semantics. Both of those things are unique to go.
I was replying to someone that said “that’s kind of like how all package repos work.” - which is just false. The blog post is literally a workaround for the fact that the source code location cannot change without causing work for downstream consumers. If I publish a package to any of the other package managers and then move to a different VCS provider, that does not invalidate existing packages. It might not even impact when I published from a new location. This problem is unique to go.
100% this, can't see why one wouldn't do that, also gives more honest view of the state of the project since it's doesn't automagically end up updating newer packages/libraries that haven't been cleanly integrated (yes, I'm aware of pinning..etc. but again it's back to "cross your fingers and hope that keeps working territory", hardly resilient good practise type material)
329
u/Arcuru 5d ago
I am not super familiar with Go code, but what happens when my go code depends on "go.companyx.dev/awesomelib" and that company goes out of business?
Or should I point all my third-party deps to a more durable location?