This is probably the most complicated way I could find to fix#1587.
Jokes aside, this was done with a few goals in mind:
- Reduce coupling between the installer and the rest of Flarum's
"Application", which we are building during installation.
- Move the installer logic to several smaller classes, which can then
be used by the web frontend and the console task, instead of the
former hacking its way into the latter to be "DRY".
- Separate installer infrastructure (the "pipeline", with the ability
to revert steps upon failure) from the actual steps being taken.
The problem was conceptual, and would certainly re-occur in a similar
fashion if we wouldn't tackle it at its roots.
It is fixed now, because we no longer use the ExtensionManager for
enabling extensions, but instead duplicate some of its logic. That is
fine because we don't want to do everything it does, e.g. omit
extenders' lifecycle hooks (which depend on the Application instance
being complete).
> for each desired change, make the change easy (warning: this may be
> hard), then make the easy change
- Kent Beck, https://twitter.com/kentbeck/status/250733358307500032Fixes#1587.
