Submodules for the individual plugin sources

[rpdelaney]

@Attano, in #2 @ProdigySim suggested that using git submodules for the individual plugins is worth considering. I agree.

Advantages:

• Clearly defined relationships between each plugin and the applications that source them downstream
• Parity between projects that reference the same source code is automatically maintained by git
• Single point of origin for shared code guarantees consistency between projects

Disadvantages:

• Submodules can be cumbersome if developers are unfamiliar with working with them
• Lots and lots of separate repositories
• May necessitate a build script to update the submodules before compiling, etc. [1]

[1]: Having a build script is probably a good idea anyway, per prior discussion also in #2.

Thoughts on this?

[ProdigySim]

I'm officially not a fan of doing submodules for this--I'd prefer larger centralization. Ideally, since EQ + Promod + other configs will all be living on the same servers together without conflicts, I'd rather work towards having a single repo that consolidates them all so conflicts can be resolved during development rather than during installation.

[rpdelaney]

Could you amplify on "larger centralization" -- are you suggesting that Promod and EQ should both be developed in a single repository?

[ProdigySim]

Yes, that's what I'm suggesting. I don't see a major downside to the centralization. It seems to me that any conflicts between the two configs are conflicts that will arise in the production environment anyway (since servers run both configs), so dealing with those conflicts in one single development environment seems way more efficient than dealing with them in the field.

(That was also what the point of the LGOFNOC/Confogl3 setup was supposed to be)

[rpdelaney]

All right. It does leave an unresolved question about what happens with forked configs that want to be compatible with promod -- we would be making their job harder by forcing them to continue to merge from upstream and sort through the history as the plugins are added, removed, updated, etc. Also, any scenario where a promod fork was abandoned and required old plugins (witchparty) would make a mess. Submodules provide neat solutions to all these issues.

However, based on prior experience, perhaps we can be pessimistic that any hypothetical fork would use git at all...

It would be fair to say that submodules are closer to theoretical "correctness" but that the real-world ROI is easy to over-estimate. :-) /jargon

[ProdigySim]

we would be making their job harder by forcing them to continue to merge from upstream and sort through the history as the plugins are added, removed, updated, etc.

Don't they have to do this anyway? They just do it from outside, via binaries. And they could still choose to operate in the same way if they want.

[rpdelaney]

You're right. It's not an argument against merging Promod and EQ development into a single repo -- it would make little or no difference to developing a fork. However, the issue I'm raising in this thread is whether plugins that Promod (or EQ) (or any other config, for that matter) depends on should be installed as submodules. That does make a difference to a developer of this hypothetical fork.

[ProdigySim]

Ah, sorry, I misunderstood your comment.

How exactly would you propose we split up the repo into submodules then? What I'm fearing is the bouncing around of plugins between different repos. Shared plugins vs forked plugins. Specifically, moving forked ones to be shared sounds quite difficult.

[rpdelaney]

As I'm reading you, you asked two questions:

1. "How exactly would you propose we split up the repo into submodules then?" I'm not sure exactly, but I think it would go something like:
   • Each plugin has a separate repository with its own source code, development history, and build script to compile it.
   • The plugins are installed as submodules in the Promod repo.
   • Promod's build script, in addition to its other behaviors, would recurse through each submodule executing the build scripts and copying the binaries into the appropriate directory structure.
2. You raised a concern about plugins 'bouncing around' between different repos. I believe this is a problem with a monolithic repo that submodules avoid by design. With the single-repo schema, a promod fork might include changes to some of the plugins, but not others. Those changes would have to be monitored by hand and merged back upstream. A submodule would not share that defect: changes to any plugin are committed to the corresponding subproject, and any other project that calls the plugin has the same updates made available simultaneously. It's really magical stuff.
3. I doubt it would ever be appropriate to fork a plugin. If one is tempted to do so, the plugin is probably too complex or has too wide a scope. Regardless, if the need to fork a plugin does arise, having a subproject would support it hugely better than a single repo for reasons that I hope are self-evident...

[Attano]

A repo for every single plugin? Seriously? Let's be realistic, is this really necessary or practical, at this point? 95% of these plugins' source code will never be touched again. Why bother?

[rpdelaney]

On the one hand, I see where you're coming from. On the other, I'm thinking "Oh yes, just think of all those precious repositories that won't have to be wasted!" :smile: They're not precious resources -- and I'll create them if that seems tedious. Anyway, it's not any kind of big deal so I'll leave it there.