4 ms·

> That advice still holds today: vendoring is still the solution to dependency management for binaries. This might be a stupid question, but can someone explai

• sudhirj 10y ago
  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.
  • fpoling 10y ago
    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.
  • fludlight 10y ago
    Is this different from statically linked libraries (as opposed to dynamically linked)?
    • NateDad 10y ago
      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.
• bitwize 10y ago
  "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.
  • bboreham 10y ago
    Just to add: the name comes from the convention of storing all those dependencies in a subdirectory named "vendor".
    • platz 10y ago
      Is vendoring strictly storing the source code, or can it include storing compiled libraries?
      • cyphar 10y ago
        Go doesn't have support for using compiled libraries (although support is coming). It's always using the source code.
• jud_white 10y ago
  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.