Question

Suppose Project X is the base project and Project Y depends on X. Project Y might be a plugin for Project X, or perhaps it is a standalone app that requires Project X in some other fashion.

I have thought all this time that Project Y should be the superproject, and Project X should be a submodule of Project Y.

However, upon reading this, it appears as though my thinking may be inverted. In the article, the dependency is the superproject and dependent code (in this case, plugins) are submodules. Is this the correct way to use submodules, then?

Answer 1

If ProjectY can live without knowing anything about ProjectX (which can be the case it it is a plugin for X), it cannot be a superproject.

If it it needs X to somehow be complete, then yes, it could be a superproject, in order to reference X within its tree (as explained in true nature of submodules).

In a component-based approach, a true superproject would be a third project which references the right version of ProjectY and ProjectX in order to record the exact configuration (i.e. list of revisions) needed for the overall project to work.

---

The OP add the right question: where do one stores the dependency (of Y on X)?

If one takes the component-based approach and has a ProjectZ superproject, and ProjectY has a dependency on ProjectX to build, do we not include ProjectX as a submodule in ProjectY’s repository, but only in ProjectZ?
This would mean that ProjectY could not be built on its own, making it (for lack of eloquence) a sort of “implied submodule.”

If you have only 2 components, one depending on the other, sure: you can directly declare ProjectX as a submodule of ProjectY.

But if ProjectY cannot been built on its own, it is not a “complete” (as in “autonomous”) project anyway.
Hence a global parent “ProjectZ”, where storing that dependency information outside ProjectY has its advantages:

1. keep each module paths more visible, directly from ProjectZ root (instead of burying ProjectX potentially deep within ProjectY, making that dependency less visible to ProjectY clients)
2. unifying ProjectX versions (if several modules need ProjectX, referencing it once in ProjectZ clearly advertise the “one official version” of ProjectX that all the other modules should use)