Hacker News Reader

Comment by lmm | Hacker News Reader

> - Vendoring dependencies using "go mod vendor" is not a good default workflow - it bloats the repo, the checked in code is impossible to review, and is generally a pain to keep up to date. Don't, unless you really have to.

Go's setup is that if you don't vendor your dependencies then your build might break at any time, no?

View on HN

Not if your default $GOPROXY is google. Google will cache that package indefinitely?

That's explicitly not guaranteed. From https://proxy.golang.org:

> Why did a previously available module become unavailable in the mirror?

> proxy.golang.org does not save all modules forever. There are a number of reasons for this…

(I am a googler, but don't work on the go team – my opinions that projects should vendor and actually review their dependencies are my own)

> proxy.golang.org does not save all modules forever. There are a number of reasons for this, but one reason is if proxy.golang.org is not able to detect a suitable license.

If you're vendoring something without an appropriate license, you're skating on thin ice legally.

That's just one possible reason. The disclaimer does not specify all the possible reasons the proxy would drop a saved version. Treating it more like a cache seems appropriate.

No, packages are stored locally in a "modcache".

Unless you're doing something stupid like "create a clean virtual environment for every build" then yea your build might break if you lose the internet or the packages disappear. Just don't ever do that stupid thing.

This is essentially he default when using most CI services, however.

Hence most CI services are stupid

Reply on news.ycombinator.com