4 ms·
"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
by akavel 10y ago
"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.
- majewsky 10y agoAnother 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.
- vbernat 10y agoAlso, 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.