understanding "go mod vendor"

Question

What is the purpose of "go mod vendor". I thought with vendoring packages will not be stored in module cache. However, if I understand correctly, I think this is not correct since we need to update go.mod first before "go mod vendor" by either "go mod tidy" or "go get". It seems "go mod tidy" and "go get" download packages in module cache. To me, "go mod vendor" seems like a copy of module cache. Why do we need a copy of module cache in our project's root directory?

One more question: What is the recommended way for setting up our environment? Let's say I am using GOPROXY and GOPRIVATE. Which one is better to use? vendor directory or module cache? or it does not matter.

I have already read this post.

Thanks!

Armijo

Vendoring is mostly a holdover from before modules, when there was no build reproducibility without copying (vendoring) third-party dependencies. I'd consider it mostly redundant today, except maybe when you want to build in a Docker container and don't want to have to fetch modules from within that container. – Sullins

Just like it was prior to modules, it allows you to check in the dependency’s source to version control. – Synectics

Answer 1

As programmers, our main pain point is always lack of control. Dependencies are a tricky thing, you cannot built anything in pure software, without depending on something that already exists. Not only the hardware, but typically the OS and its drivers, and potentially external libraries.

External libraries is where Go modules come in. You use go mod tidy and go get to download dependencies from the internet when you do not already have them on your computer.

Once you have the libraries, you can use go mod vendor to copy them from your system's Go cache directory to the actual repository that uses them. You check in these dependencies into source control. This way you have total control over the code you depend upon. These dependencies are now part of your code, you own them now. You actually own them, even if you do not vendor them, but you lack control over them, which is a situation that is to be avoided if you like your code future-proof.

Once you have your code with all its library dependencies vendored and uploaded to GitLab (for example), it does not matter whether the original owner of a library you depend upon pulls the rug from under you and removes their library from GitLab, for example. You now have one potential problem erased from your list. That is the reason why vendoring makes sense.

Marentic

Thanks @gonutz. This is the most simplified and clear answer I have come across for go mod vendor. – Oddfellow