Module load order is not defined

[dlamkins]

Modules currently load in a somewhat undetermined order. In reality it's dictated by the order returned by windows when we enumerate the modules directory, but this isn't strictly defined anywhere and just results in modules loading sorted by their namespace alphabetically (as modules are always saved using their namespace as the filename).

Further, modules which are launched via the launch flag will run first which can cause slight discrepancies between debug and standard launch behavior, and we want to avoid that where possible.

Finally, modules can depend upon other modules. We do enforce this partially for users (preventing them from enabling when a module dependency is not met), but when automatically enabling modules, we don't enforce the dependency load order. This is especially obnoxious when creating a module which depends on another module as the developed module will always load first.

Since modules can be enabled or disabled at any time, this can become problematic - especially when module updates are involved.

Ultimately, we have two needs:

• Load order should be deterministic: based on a dependency sort.
  • We don't care too much beyond that the load order as module loading is asynchronous and should not greatly impact other loading operations. That is to say, there shouldn't be much of a performance advantage for modules loading sooner rather than moments after another module. In practice, this may not be accurate due to resource loading locks, etc.
• When a dependency is disabled, the dependent modules should also be disabled (in the correct order).
  • This is especially important for automatic updates which may suddenly (from the perspective of other modules) make a dependency unavailable.
  • This will likely require some UI improvements to indicate on a dependency when there are modules requiring it.

[dlamkins]

We will want to decouple the loading of modules from the stage that we enable the modules so that we can:

1. Load
2. Sort
3. Enable (if the user has the module enabled)

This also means that we can't load all modules at the same time if there are dependencies. Secondary modules will need to wait until their dependencies finish loading.