Dep: Are there any plans to add git submodules support ?

[mohanraj-r]

An alternative to use dependency management tools like dep would be to use Git - Submodules to checkout the dependent repos into the vendor directory. There has even been some 3rd party tools that attempted to solve the dependency problem using git submodules.

Given there are some advantages to using git submodules to vendor dependencies, wondering if there has been any discussion or consideration towards supporting git submodules in dep as an option to vendor dependencies ?

[sdboyer]

hi, welcome! thanks for the question - this is probably one we should put into the FAQ, it's come up a number of times.

No, git submodules are not going to be a part of dep, beyond the one tiny bit of support we have now (we preserve /vendor/.git, if it exists - cockroachdb uses this technique to keep vendor from bloating their primary repo size). Here's the pro/con list on it:

Pros

• git submodules provide a well-structured way of nesting repositories within repositories.

Cons

• The nesting that git submodules perform is no more powerful or expressive than what dep already does, but dep does it both more generally (for bzr and hg) and more domain-specifically (e.g. elimination of nested vendor directories).
• Incorporating git submodules in any way would new fork new paths in the logic to handle the submodule cases, meaning nontrivial complexity increases.
• dep does not currently know or care if the project it operates on is under version control. Relying on submodules would entail that dep start paying attention to that. That it would only be conditionally does not make it better - again, more forking paths in the logic, more complexity.
• Incorporating submodules in a way that is at all visible to the user (and why else would you do it?) makes dep's workflows both more complicated and less predictable: _sometimes_ submodule-related actions are expected; _sometimes_ submodule-derived workflows are sufficient.
• Nesting one repository within another implies that changes could, potentially, be made directly in that subrepository. This is directly contrary to dep's foundational principle that vendor is dead code, and directly modifying anything in there is an error.

[mohanraj-r]

Thank you @sdboyer for the detailed pros/cons.
And thanks for adding it to the FAQ 💯

[mewmew]

Thanks, I was also wondering this and the detailed explanation gave me a good ponder. Thanks @sdboyer!