"Pros" are listed, but "cons" are not. While evaluating git submodules as a possible solution for vendoring at my work, I found the following disadvantages with this model:
- you can use only git dependencies (no bzr, hg, ...); though most stuff is on github nowadays (especially with closure of Google Code), still not necessarily everything. With pure submodules you're locking yourself in the git monoculture.
- you must trust your dependencies will not ever disappear (see "the leftpad problem", or the mentioned closure of Google Code).
That said, all approaches have pros and cons. Though I admit I usually don't like advertisements which only show advantages and don't list downsides.
Also, it is not possible to express constraints (eg. follow 2.x tags). A manifest file is handy for that.
Personally, I like glide better since it takes a lot from Ruby bundle. I commit only glide.yaml and glide.lock in the repository. It is not flawless either as each operation triggers an update of all dependencies.
Another con is that submodules will be missing in the tarballs that Github autogenerates for tags and releases. I initially used submodules for my own Go binaries, but moved to a custom vendoring solution since then.
I'm using subtrees to vendor C dependencies and it works well. Submodules are problematic as they may disappear or the git repo might be down. If your dependency is read only, subtree is a better option IMO.
Glide isn't ideal either. It gets confused about vendored dependencies by 3rd party libraries and tries to download them separately.
Also, it's invented it's own format for the deps and lock files instead of trying to standardise on the ones already out there.
Yes. It's a terrible mess. But as of GopherCon a couple of weeks ago, the way forward is becoming clear. Most important, the Go Team is now in direct communication with the authors of the most widely used vendoring tools, and it seemed to be widely acknowledged that this is a severe problem, that a standard is needed, and that even things like "go get" might have to change. I'm very hopeful.
I'd much rather them forget reverse compatibility and fix the core problem once and for all. I personally like gb and the ability for each project to be its own GOPATH.
Putting your dependencies in a folder called "vendor/" is standard, but how you get them there isn't.
There's a collection of tools for managing that, like this one , and others like "godep" and "glide". Which one you use for that doesn't seem to be settled.
Manul is one of the very limited set of tools which provide idiomatically go-gettable projects without need of vendoring tool be installed on the user machine.
> Some copy the source code of dependencies into the vendor directory:
I don't agree with any of the stated problems there. Unless you are building a library you should commit your dependencies and not rely on third party repos being available.
I can't stress enough how useful govendor [1] is if you do Go professionally.
Copying the source code of the dependencies into your repo isn't the only alternative to relying on third party repositories, though.
You could fork the dependencies that you work with into locally managed repos and use submodules to include them in your own project. That way you can easily update your dependencies without breaking everything and also maintain their commit history.
That's how we started back in the day. It works but setting up everything and doing the rebase/commit dance to update can be quite cumbersome when you have more than a couple dependencies. Nothing wrong with it if you are willing to do the work though.
Does the go toolchain allow you to freeze your dependencies to specific versions like pip, etc? I think that could be preferable to committing all your dependencies.
The go toolchain doesn’t but many of these vendoring tools do something similar. But you still don’t want to depend on the origin repo being up and have missing/altered repos break your builds.
If you depend on A and B and both depend on C, you now have the npm2 style heirarchy of nested dependencies.
As with all 'use submodules' solutions, the devil is in the detail with the nested heirarchy of dependencies and version resolution.
I mean, fwiw, its quite nice for simple 1-level-deep dependencies, but this isnt a simple problem. What if A -> C@1.1.5, and B -> C@1.1.9. Do you install both? Only one?
You might still be able to solve it somehow, if the submodules are required to have semantic version tags on their versions, you parsed the entire hierarchy and then resolved conflicts (somehow), based on the semver semantics... I guess?
That's outside the scope of this tool. Go has already adopted the npm style submodules that you mentioned (I.e. Answer = you install both versions in their respective vendor/ dirs).
This tool just tries to help you manage that. Not that I'm a big fan, either way, but still.
If you're not a fan of submodules, but are in need of a this kind of tool, I'd recommend looking at `glide` [1] . I've had much better experiences, as a user, with `glide` than other tools, and it supports package aliasing which is really helpful. (Package aliasing allows for satisfying an import path with a private fork of a package, without having to rewrite all the import statements inside my fork.)
- you can use only git dependencies (no bzr, hg, ...); though most stuff is on github nowadays (especially with closure of Google Code), still not necessarily everything. With pure submodules you're locking yourself in the git monoculture.
- you must trust your dependencies will not ever disappear (see "the leftpad problem", or the mentioned closure of Google Code).
That said, all approaches have pros and cons. Though I admit I usually don't like advertisements which only show advantages and don't list downsides.
Personally, I like glide better since it takes a lot from Ruby bundle. I commit only glide.yaml and glide.lock in the repository. It is not flawless either as each operation triggers an update of all dependencies.
(see: http://blogs.atlassian.com/2013/05/alternatives-to-git-submo... and https://codingkilledthecat.wordpress.com/2012/04/28/why-your... )
I haven't found anything on the conference site.
There's a collection of tools for managing that, like this one , and others like "godep" and "glide". Which one you use for that doesn't seem to be settled.
> Some copy the source code of dependencies into the vendor directory:
I don't agree with any of the stated problems there. Unless you are building a library you should commit your dependencies and not rely on third party repos being available.
I can't stress enough how useful govendor [1] is if you do Go professionally.
[1] https://github.com/kardianos/govendor
You could fork the dependencies that you work with into locally managed repos and use submodules to include them in your own project. That way you can easily update your dependencies without breaking everything and also maintain their commit history.
If you depend on A and B and both depend on C, you now have the npm2 style heirarchy of nested dependencies.
As with all 'use submodules' solutions, the devil is in the detail with the nested heirarchy of dependencies and version resolution.
I mean, fwiw, its quite nice for simple 1-level-deep dependencies, but this isnt a simple problem. What if A -> C@1.1.5, and B -> C@1.1.9. Do you install both? Only one?
You might still be able to solve it somehow, if the submodules are required to have semantic version tags on their versions, you parsed the entire hierarchy and then resolved conflicts (somehow), based on the semver semantics... I guess?
This tool just tries to help you manage that. Not that I'm a big fan, either way, but still.
[1]: https://github.com/Masterminds/glide