Unify the installer into a single package that is part of our subtree split
>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3574406. --> Reported by: [phenaproxima](https://www.drupal.org/user/205645) Related to !814 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>I originally created Recipe Installer Kit before Drupal CMS 1.0 in an attempt to balance several concerns:</p> <ul> <li>Disposability: the installer is a one-and-done thing. It should be deleted, and more than that, it should be <em>easy</em> to delete. The vision was that you wouldn't need to use Composer to delete the installer; you could just delete it. I also didn't want other people taking Drupal CMS's installer, trying to co-opt it for their own project, and then complaining if it didn't work.</li> <li>But that was at odds with being able to update the code (for security, compatibility, and so forth).</li> </ul> <p>Recipe Installer Kit was made in order to have an actual package that could be updated, but that would allow us to also have a thin profile that could be deleted with ease. It has fulfilled these goals.</p> <p>But...it's getting pretty hard to maintain, for several reasons:</p> <ul> <li>It's not a Drupal extension, so it's hard to test.</li> <li>I might be <em>the only</em> person who understands it.</li> <li>The fact that it does most of the heavy lifting on behalf of a profile means its architecture has to be twisty and awkward.</li> <li>I'm not sure anyone but us actually uses it for anything.</li> <li>None of this would actually prevent someone from co-opting our installer for their own purposes. They could just copy our theme and code.</li> </ul> <p>In other words, the added complexity no longer justifies the benefits...if, indeed, it ever did.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Refactor our installer into a single package, an install profile called <code>drupal_cms_installer</code>, and make it a runtime dependency of the project template. The package's source code will live in our repository and be part of our subtree split.</p> <p>The profile will contain its own theme, since the theme and installer are tightly coupled. It will also have all the internal logic that Recipe Installer Kit did, but without the support for <code>drush generate</code>.</p> <p>Meanwhile, Recipe Installer Kit will be marked as deprecated, with no further development taking place.</p>
issue