It solves the problem of reproducible builds when using third party code. You can record state (v 1.3 of pkg foo) or check in code (vendor).
It only really gets complex on big projects with lots of dependencies which themselves have dependencies.
It only really gets complex on big projects with lots of dependencies which themselves have dependencies.
"Vendoring is the act of making your own copy of the 3rd party packages your project is using. Those copies are traditionally placed inside each project and then saved in the project repository."
Being familiar with both Maven and npm, in those communities, this act of checking dependencies into source control is a controversial and hotly-debated topic, but in those package managers is more often than not (please bear with my point) considered an anti-pattern, because both of them provide solutions [2][3][4], like a project's declarative list of dependencies along with a baseline (but often, overridable) conflicting-version-resolution algorithm.
Of course, the more I understand the issue, the more questions I have.
Why does Go have multiple, competing package managers? Some, like Glide [5] (without judgements about all the others), encourage the type of declarative version management I quoted.
Why does Go even ship with built-in package fetcher 'go get'? Why would anyone ever build a package fetcher for a publicly-released ecosystem that has no concept of versions or commit-IDs or content-adressed-hashes, or some other mechanism of tracking state to something that's as inherently mutable as a software package?
I have no desire to point fingers, and I don't want to encourage bikeshedding, and I don't want to turn this sub-thread into an in-band debate, as I'm certain it's been done (over and over again) in the past, I just simply feel that 'go get' is fundamentally broken in its understanding of how people in the wild actually write software. I'm suddenly beginning to understand why there are concerted efforts [6][7][8] to address this issue in a community-led, officially-sanctioned way.
[1] http://stackoverflow.com/questions/35109393/ [2] http://maven.apache.org/guides/introduction/introduction-to-... [3] https://github.com/ning/maven-dependency-versions-check-plug... [4] http://bytearcher.com/articles/semver-explained-why-theres-a... [5] https://github.com/Masterminds/glide [6] https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsW... [7] https://docs.google.com/document/d/1M4Ldgtxr9vC8wpyTldQe5oUy... [8] https://github.com/sdboyer/gps/wiki/Rationale
Vendoring also works just fine for many uses and has the virtue of making dependencies explicit.
Pkg management is useful if you have a large ecosystem of rapidly changing libraries with many fragile dependencies which overlap. If can encourage overuse of external code though (eg left-pad).
It is not a panacea or the one true way.