Go Module Vendoring is a Lifesaver

Posted: 2022-11-19 #programming #commentary
3 minute read.

A couple of months ago, I wrote a post of my praise for go “package manager”. In this post I will take a look at one of its best features, vendoring.

A module is “vendored” when all of it’s dependencies are saved & organized to a vendor/ directory in the module. Its a local version of the dependencies source files all within your project tree. Now a multitude of reasons will come to mind on why a feature like this is useful, but I want to point out where it is really useful, building for production.

Python is one of the languages that I have used frequently in a production environment, thus I have be come painfully familiar with its package manager. To be frank, python packaging does not want to be portable in the slightest, you always have to have the latest and greatest to do anything with it. Some devs try to have LTS releases, but it usually never scales up to what is wanted. What hurts even more is there’s no way to have a local tree of dependencies with python, you just have to be proactive in auditing your 1000+ line requirements.txt to make sure everything is the version you want. Or you could use git submodules, but that’s even a bigger pain, especially considering that you would have to so the same for every dependency of the dependencies¹. So if you wanted to have the actual code in your project, its a lost cause.

Go fixes this problem by reducing the packaging tools and requirements to just 2 files in your module’s root. The toolchain will then look at the go.mod for your dependencies and fetch them from wherever they may be. You can optionally vendor the dependencies to a local tree with:

$ go mod vendor

Thats it, now all your dependencies’ sources are in the vendor/ directory in your module root. If the build was successful, you now have a line-for-line reproduction of all of the required dependencies that you can most certainly add to your VCS² without any toolchain wrangling. No matter where the code goes, you have all the required sources to build. Its a small feature, but removes a lot of friction from managing dependencies with a package manager, since you can update sources only when you need to do so.

Tickles my C purist itch, but with a modern approach that is reasonable. I like it.

Have a comment or question? Shoot an email to ~theorytoe/public-inbox@lists.sr.ht, my public inbox.