In Go, it's customary to use 'go mod vendor' to put your dependencies into the main repository. While it's not universally recognized as a good technique, it saves the adopters of this approach from the downtime today.
These days with go mod and the go team maintaining their proxy there is very little benefit to vendoring and any benefit is not worth blowingup up the size of your repos and messing up code reviews on PRs that introduce new dependencies.
I've never had to use -mod=vendor, so I just looked it up:
-mod mode
module download mode to use: readonly, vendor, or mod.
By default, if a vendor directory is present and the go version in go.mod
is 1.14 or higher, the go command acts as if -mod=vendor were set.
Otherwise, the go command acts as if -mod=readonly were set.
See https://golang.org/ref/mod#build-commands for details.
If there's a vendor directory, it's used by default. As for my two cents, I use it frequently when building Docker images so that I don't have to pass secrets into the image to clone private modules (but I don't check the vendor directory into Git).
With more outages of our amazing, but overly centralized development ecosystem, the popularity of this approach will likely surge. It helps that Go supports the vendoring workflow as it makes the choice practical.
As for building with a flag: true, but very minor, as it's rare to execute 'go build' directly. In most projects I've seen, it's either Bazel, or some kind of "build.sh".
Maybe the key point is to choose consciously and pick the option that gives the best combinations of tradeoffs for your situation vs just doing what is easy or copying what other people are doing without understanding you're making a decision with various tradeoffs and consequences. Tradeoffs that are a good fit in other contexts may be a poor fit for your situation.
If one of the goals of your build process is to be able to guarantee reproducible builds for software you've shipped to customers, and you depend on open source libraries from third parties you don't control, hosted on external services you don't control, then you probably need your own copies of those dependencies. Maybe vendored into version control, maybe sitting in your server of mirrored dependencies which you back up in case the upstream project permanently vanishes from the internet. But setting up and maintaining it takes time and effort and maybe it's not worth paying that cost if the context where your software is used doesn't value reproducible builds.
Google takes care of storing copies of any go dependency you use on their proxy, there is very little reason for you to maintain your own via vendoring. Maybe if you are a big enough organization you run your own proxy as an extra layer of safety above google but still I don't see the value of vendoring these days.
Go uses a proxy for downloading modules, so there's no Github involved. And you could run your own proxy-cache if you wanted. In addition, your work machine has a local proxy cache of the modules you already downloaded.
Go doesn't use a repository as a single source either, which is another problem in of itself.
