Hacker News Reader

Comment by krat0sprakhar | Hacker News Reader

> That advice still holds today: vendoring is still the solution to dependency management for binaries.

This might be a stupid question, but can someone explain to me what this means? Thanks!

To vendor a dependency is to store a copy of all the source code you're trying to use inside your project itself. That way, when you compile your project, you also compile the code it depends on.

Updating code you depend on is a semi-manual process - you choose to copy the latest version of the code you depend on into your project again.

This is contrast to stacks like Java, where I can give you a pre-compiled JAR file that you can link your code to.

I have found that using git-subrepo is a great help with vendoring as single

    git subrepo pull --all

is enough to update all dependencies.

Is this different from statically linked libraries (as opposed to dynamically linked)?

This is about code, not libraries. Vendoring the code means copying it into your own repo... that way you're guaranteed that everyone who builds your project is building the exact same code, and if one of the third party repos disappears, your project doesn't all of a sudden fail to compile.

"Vendoring" means maintaining local copies of third-party libraries and other dependencies in your local repo so exactly what you depend on is a part of your internal history. Git provides ways of doing this easily, such as subtrees.

Just to add: the name comes from the convention of storing all those dependencies in a subdirectory named "vendor".

Is vendoring strictly storing the source code, or can it include storing compiled libraries?

Go doesn't have support for using compiled libraries (although support is coming). It's always using the source code.

A point of clarification for anyone skimming the original article:

> Top Tip — Libraries should never vendor their dependencies.

Peter goes on to clarify:

> You can carve out an exception for yourself if your library has hermetically sealed its dependencies, so that none of them escape to the exported (public) API layer. No dependent types referenced in any exported functions, method signatures, structures—anything.

I think this is the way to go if you're writing a library which has its own dependencies. You get a repeatable build and free yourself to change which dependencies you rely on without impacting users of your package.

There are exceptions, such as if your dependency has an init which only makes sense to run once. Loggers come to mind, where the setup should be determined by the main package. The f.Logger point in the article is friendlier to users of your package than just using log.Printf, and frees you from having to vendor logrus, for example, if you want to support structured logging.

Reply on news.ycombinator.com