Implement the idea of submodules

[displeased]

Having a flat configuration layout (as-in, everything is in a single directory with no nesting) is all well-and-good for simple configurations; However, when some configurations start requiring nesting within other configuration's install directories, that is to say when some configurations functionally become children of other configurations, a flat directory can become complex with redundant and overlapping configuration names. For example:

I want to configure my .ssh directory with my ssh configs. Well, that's simply, I just create a new configuration that targets .ssh with the file config. But, if I'd like to modularize my configurations under a directory in .ssh labelled config.d, I would need to make a whole new folder to nest under .ssh, meaning a whole new install location, meaning a whole new configuration in ddm-land. It would be much easier if I could declare that one configuration relies on another configuration.

This is all to say, there should be a tool outside of different configuration names for managing complexity. Also, it wouldn't hurt in the process to create a method of declaring child-and-parent relationships.

[displeased]

First thought that comes to mind - we expand the standard with submodules; but, what are submodules practically? (A Q&A game with myself)

What will it look like?

Submodules will reside in a new directory under a configuration's main directory (conf adjacent) under the name sub. When the install conditions are met for installing the submodules of a configuration, ddm will be run in this folder as-if it's a normal root-level ddm folder.

Install Conditions?

For now, submodules will be installed if their parent can be installed. Any selective-installation will be relegated to the submodules themselves. Conditional submodule installation may turn into a feature in the future (it might be useful to install all submodule dependent on a condition).

Will this allow multiple nesting?

If ddm algorithm's are design to be nesting-agnostic, yes?

How will cache files be propagated?

Good question, I'm not sure right now. But cache files are the only state that really persists when it's written to file. All cache files will continue to be formed at the root-level, so some sort of state needs to persist.

[displeased]

tmux is an interesting case study here - it sets an environment variable when it executes which I think is read by different tmux sessions to determine what's going on?

Applying this same methodology to ddm would mean that ddm would set an environment variable $DDM when it starts up for the first time. Any subsequent instances of ddm would check this environment variable to inform where they put their cached entries.

To prevent concurrency issues, this system could only launch one child instance at a time though....