The primary focus is to remove the scripted installation system that has to fake caches and all kinds of other ungodly things and simply brute force system and user modules into a SQLite database in the temporary directory and then install Drupal to the primary database from that partial environment. The primary benefits:

  • installer can be written as a module and has access to a proper Drupal environment
  • all normal hooks are fired when installing modules (opens up all kinds of interesting possibilities in addition to fixing bugs/inconsistencies depending on when module in installed (by profile or later))
  • we remove the inconsistent behavior of the initial installation system as compared to the module administration once Drupal is running
  • get rid of a ton of code that we never have to see or maintain again

This would require SQLite for installation, but not runtime.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

boombatower’s picture

Copied from http://drupal.org/node/1153716#comment-4738060:

I have a very rough initial installer written that actually seems to work.

I am working with the following approach.

- hit install.php
- generates extremely minimal database in sqlite in temporary directory so as not to require any setup
- you are then redirected to drupal site running off the sqlite database
- the installation wizard runs as a module inside a standard drupal environment
- user fill in database information, select profile, etc.
- the installer module then installs all the modules for the selected profile (which will then include system) on the actual database
- the temporary sqlite database is destroyed and the user is redirected to the installed drupal site

I currently have the initial sqlite database being generated in a temporary directory such that you can actually view the drupal site running off it with only system and user partial enabled (don't need all the tables, we could install them all just for simplicity sake and leave the schema definitions there instead of dealing with common schema and what not).

The current installer code that gets the basic drupal site running is very small (which is the idea). It will be the only piece of the installer that does not run in a drupal environment. This allows the rest of the installer to run with proper caches, form system, hooks, etc so that it no longer behaves weirdly and has an entirely separate code base. The current code I wrote is copied and pasted (with lots of commented out code and some hard coded data) and remains at just over 200 lines (it's VERY minimal).

The next step then is to write the installer.module which I would say we do from scratch (most likely lots of copy and paste, but massive restructuring) as we have a complete new methodology, environment, and options. We can mimic the old one or make something totally new I mean you could download and browse modules from d.o during initial installer...all kinds of crap. For now I vote we just mimic the old one. The only option I would open to discussion is the use of the maintenance theme or not, since we can easily use a real theme since we have the full environment...then it will look and feel as a regular drupal site.

An option to consider is that once we get the real database information we copy the sqlite database into it and reload the site...so we are simply building from there. I somewhat like the idea of simply switching database connections and installing all the modules in the real database, while the installer runs (boots) off the sqlite database. This ensure that system module can be installed in a drupal environment as well.

Using this new installation method one could write a script to invoke initial install, bootstrap, and simply run module_enable(array()) instead of having a huge scripted set of crap.

// custom install script (rough idea)
install_initial(); // w/e
install_database_info($database);
module_enable(array('my_module'));
boombatower’s picture

Obviously another option would be to require database credentials (either in initial form, or directly in configuration file) to negate the need for SQLite.

kika’s picture

How different is this from chx's #332303: bootstrap from sqlite from 2009?

boombatower’s picture

My understanding of chx's approach was to store configuration information in sqlite to replace settings.php. This patch uses sqlite (or any other database) to perform a brute force ultra minimal installation (user and system modules), runs the installer as a module itself, and performs the installation from a proper Drupal environment.

tstoeckler’s picture

I think this is only viable if we actually require SQLite. While #2 might be doable technically, it would put a burden on people without SQLite (and without the ability to install it), which is really only people on shared hosting. And for those people such a UX regression (having to enter the database creds manually into settings.php instead of having a nice installer) is critical.

I just did a very quick, very unscientific study on the availability of SQLite on shared hosting and for those providers I checked (mostly German ones) it seems to be the baseline that SQLite support goes hand-in-hand with PHP5 support, which literally everyone has, nowadays even in the bottom end of the pricing range. This would of course have to be researched more profoundly. I don't know, though, whether that should be done in this issue or in a dedicated issue.

boombatower’s picture

From #2

either in initial form, or directly in configuration file

meaning we can present the same sort of form as was there before for those without SQLite. Interesting note on the availability of SQLite though.

David_Rothstein’s picture

If you have in-progress code for this, it would be awesome to post it here. Right now I'm having trouble understanding how SQLite simplifies things, though.

Currently, the installer basically does this:

  1. Choose profile
  2. Choose language
  3. Check requirements
  4. Enter database credentials
  5. Install system module and bootstrap Drupal
  6. The rest (Drupal is fully-bootstrapped throughout)

Your proposal would allow the "Enter database credentials" step to move after the bootstrap (at least for servers that had SQLite available), but I'm not sure I understand how it allows the others to move, and without moving them too it's not clear how much code simplification there can actually be.

For example, in order to successfully install the SQLite database and get Drupal bootstrapped in it, don't we have to do (at least part of) the requirements check first? And if we do that and want users to be able to see any requirement errors printed in their own language, don't they also have to pick the language first? Etc.

boombatower’s picture

Tweaked yours steps representing current system for proposed change.

  1. Check requirements (Drupal core only)
  2. Enter database credentials (optional if sqlite)
  3. Install system module and bootstrap Drupal
  4. Enable installer module and proceed through wizard
  5. Choose profile
  6. Choose language
  7. Check requirements
  8. Enter database credentials
  9. Install everything in final database

From my experimentation is seems that Drupal is only partially bootstrapped and the installer code "forks" many existing core API/code to provide special version during install..which actually behave differently (many issues related to this and what made me want to start this issue). It would seem the installer loads all the code, but the system doesn't end up acting like a normal Drupal install in terms of hooks, caches, etc.

boombatower’s picture

Assigned: Unassigned » boombatower
FileSize
6.5 KB

This is a very rough initial code that I got working. Lot of copy-paste, debug code, and plain mess. Much room for cleanup and what have you.

You'll see I ignore unnecessary tables...I just wanted to see how few tables are "required" to get minimally functioning Drupal install that I can clear and build caches from scratch. You can remove a few more tables if you brute force the caches. I get the feeling the final version will remove the ignore lists and or move those tables out of system_schema().

joachim’s picture

> Obviously another option would be to require database credentials (either in initial form, or directly in configuration file) to negate the need for SQLite.

Wouldn't this be far, far simpler than using SQLite?

Is the form that asks database details further in the process for a usability reason? What are the usability implications of having it first?

kika’s picture

I do not see pushing DB step to first as a big UX problem. Can someome recap the new UX and underlying API arcitecture flow when we get the credentials first?

joachim’s picture

Issue tags: +Needs usability review

The language selection should happen earlier, so the user sees the form in their language.

But then currently on D7, language selection comes after profile selection.

Tagging for usability review.

boombatower’s picture

Asking for credentials is more work then just using sqlite which requires no credentials...so again we can use sqlite if found and fall back to asking for credentials.

I had thought about language selection...it is only an issue if we have to ask for credentials, but I suppose we can attempt to ask for it. The issue is the more things we ask before doing initial install the more hack code we have to have that runs outside of a standard Drupal environment.

tstoeckler’s picture

I think we should seriously research whether it would be feasible to require sqlite. That would allow for a pretty clean implementation.

boombatower’s picture

That would definitely be preferable, and possibly as a last resort (option) allow ppl to add settings.php with db info, but "require" sqlite...just to be flexible.

Bojhan’s picture

I want to give feedback, but I am unsure what is being proposed from a UX perspective. The current workflow has matured of the years, and seen little big UX issues in the past 2 years. So, I understand technically we are making huge gains here but what are we gaining from a UX perspective.

joachim’s picture

I brought UX in on this because as far as I could tell, the initial problem was:

"We have to mess about without a database because we ask the user for info before we have the db set up"

To which I said:

"So how about we ask for the database details in the first step?"

Hence tagging this UX, as I imagine there are reasons for the current order of steps, but I don't know them.

kika’s picture

Not sure I followed the new clean installer API flow proposal correctly but here's my impression:

Current flow

1. Choose profile
2. Choose language
(3. Verify requirements)
4. Set up database
(5. Install profile) -- a.k.a progressbar
6. Configure site
7. Finished

New flow, if SQLite-bootstrap-based installer API approach is chosen AND SQLite is available

1. Choose profile
2. Choose language
(3. Verify requirements) -- to what step these go?
(4. Install profile) - is it needed? or will it be provided by pre-packaged sqllite dump?
5. Configure site
6. Finished

(Still confused here when MySQL/PostgreSQL DB will come into picture)

New flow, if SQLite-bootstrap-based installer API approach is not chosen or SQLite is not available

1. Set up database
2. Choose profile
3. Choose language
(4. Verify requirements) -- to what step these go?
(5. Install profile)
6. Configure site
7. Finished

kika’s picture

Note that the issue "we should not push language section that late in the flow" is already violated in D7: we offer profile selection _before_ the language selection.

tstoeckler’s picture

@#20: That's because different profiles can ship with translations in different languages, so that's really a technical limitation.

joachim’s picture

Is that really a technical limitation?

We know which languages Core install profiles offer, so we could have this:

Step 1: choose language.
Step 2: choose profile:

[] Drupal core [shown translated]
[] Other profileA [shown translated]
[] Other profileB (this profile is not available in your selected language) [shown in English]

Obviously if they choose profileB then they need to be asked their language again, which is a UX WTF.

So I guess it's a tradeoff between how many people you help by asking for language in step 1 vs how many people you make go 'WTF' by asking for language twice.

tstoeckler’s picture

We know which languages Core install profiles offer

That's only theoretically true. What languages are available really depends on what you have downloaded from http://localize.drupal.org. You can download different languages for different profiles, in theory. So you choose the profile first and the Drupal looks in /profiles/$profile/translations which languages are available.

In a perfect world, we would show all available options (as in, all registered languages on http://localize.drupal.org) and then download the appropriate file(s) ourselves, and then probably show an info message, if the translation isn't complete yet. But that's not where we are currently, at least with core.

kika’s picture

is #19 correct so far?

boombatower’s picture

#17: From a UX perspective we have a full Drupal installation to work with so we can use a real theme and anything that Drupal can do instead of a crippled hack.

#19: Please see #9.

#20-23: Somewhat relevant since we can go ahead and change this if possible, but lets stay focused on the primary topic at hand.

It seems the first task is whether or not to "soft require" SQLite with a hack method being direct entry of credentials through settings.php or to allow a graceful fallback (which introduces a number of complexities and require that we keep code outside of a standard Drupal workflow [which sucks]). #6 seems to indicate that SQLite is quite widespread and might be possible to just use. Not sure exactly how we need to proceed in terms of evidence gathering/research and who can make a final say.

Another thought, could be a sqlite packaged with Drupal download option for those that don't? Firefox and a number of application come with their own embedded versions so something tells me that shouldn't be very hard and could even lower the barrier to get Drupal running as people could just run out full/test site out of sqlite and never have to setup a standard DB. The binaries are extremely small http://www.sqlite.org/download.html.

Drush is looking into shipping with a webserver which could be interesting we could do the same with Drupal core, combined with SQLite you could download Drupal and have it just run automatically, nothing else required...for the lowed user or someone experimenting with it. Somewhat off topic. Either way being able to require SQLite for install would be very handy.

kika’s picture

Some comments on #9:

1. Check requirements (Drupal core only) -- this happens in what environment? it needs minimal installer theme support and minimal installer APIs, right?
2. Enter database credentials (optional if sqlite) -- same as 1.
3. Install system module and bootstrap Drupal
4. Enable installer module and proceed through wizard
5. Choose profile
6. Choose language
7. Check requirements -- dupe?
8. Enter database credentials -- dupe?
9. Install everything in final database

boombatower’s picture

Well #7 would be the requirements for the profile you selected...so if it has additional requirements beyond core.

#8 database credentials are for the final location to install...there will also be an option to use the database used for the first step (aka sqlite or #2).

kika’s picture

Thanks @boombatower for clarification. Still wondering about steps 1. and 2. How those will be rendered, what kind of formAPI / theme / UX environment is available for them?

As soon as there's some real progress on this grassroot initiative, UX needs likely to spin off to a separate issue.

boombatower’s picture

#1: would be a simple error message or skip to next step
#2: I would like to avoid for the reason that it would require some hackish form api (aka by requiring SQLite or allowing those without to just enter credentials into settings.php...it can obviously display a message indicating that they should do so)

chx’s picture

Um. http://drupal.org/node/332303#comment-1100495 said "Our ultimate goal is to make Drupal run out of the box and turn the installer into a normal module. Small sites can run from SQLite , once the write concurrency outgrows that, users can run the installer and install into MySQL."

Of course I so approve of this issue, finally someone who is not me doing it.

boombatower’s picture

After a conversation with webchick in IRC I created the following module to make it easy to collect SQLite availability data. This combined with some broad research should be able to get a us a feel things. I would like to announce this to get general Drupalers to submit results, but not sure if I should publish to planet, core g.d.o group or what. Hopefully get some thoughts.

http://drupal.org/project/sample
http://survey.reviewdriven.com/results (simple site: views, views_field, services that could be turned into install profile)

Please review the sample module (we can abstract it for future use later) and ensure that my detection methods are solid and should not cause fatal errors.

geerlingguy’s picture

I've been testing using Sample.module on a few of my servers and shared hosting/VPS environments. With HostGator, Hot Drupal, and DreamHost, no problem, all tests passed. However, on one VPS and a dedicated server running CentOS 5.5 and custom-configured PHP/SQL, I got a 500 error when trying to get to the sample.module configuration page.

[Edit: I've opened #1273340: 500 Error when trying to view configuration page for the problem I reported above].

yareckon’s picture

Would just like to point out a couple of points for the benefit of those less familiar with sqlite.

1) sqlite is a full relational sql database that stores its data in a single file.
2) It is public domain licensed so the client needed to interpret its data files is bundled with almost every OS, most linux distros, macs, iphone, android etc.. and independently inside many applications, like firefox, thunderbird etc.
3) Unfortunately, one DOES still need that sqlite client driver, which would be a new OS-level dependency for drupal, like php5.2 or a web server.

Gábor Hojtsy’s picture

Since there is so much discussion on the place of language selection here, note that Drupal 8 plans to make language selection/support independent of the profile via integrating l10n_update.module in core and consequently the D8MI initiative plans to move the language selection screen as the first screen of the installer. See #1260716: Improve language onboarding user experience.

boombatower’s picture

Which only effects things if we can't use sqlite (or fallback). Still doable, we just need to make a decision. I just noticed that drush 5.x has auto drupal installer depending on sqlite. Something tells me based on evidence that sqlite is fairly common and will only become more so, especially by the time 8.x is released. Prioritizing with fallback seems to make the most sense.

Owen Barton’s picture

Sqlite is very common, but I don't think it is universal enough for us to rely on - perhaps by the time 8.x is out, but it's hard to say. If we can't rely on it and need to keep & maintain the old install.php system too, then that doesn't seem like such a good option.

One option I was thinking of was to have a "blackhole" default DNTNG driver, that discards DMLs and responds to SELECTs with an empty set (perhaps with a few hard coded exceptions, such as user 0 & 1). So the site can bootstrap against this "database", then the installer module can set up the real database config, then ensure it is set as the active database when the install code/hooks are called. Is there anything I am missing here?

boombatower’s picture

Well, currently Drupal won't boot without a specific set of table data as I described above. There are movements to get Drupal to the point where it does not require db to bootstrap and that would be helpful, but quite far off.

Owen Barton’s picture

Yes - my suggestion was to have the database feed it just this initial data from hard coded arrays and blackhole (or statically cache over the course of a single request) all DML statements. Of course, it would be great to remove dependencies on the db altogether, but this provides a stepping stone.

boombatower’s picture

Not a bad idea. So we could basically just make a php array database driver that loads things from files with var_exported() data. Then we just provide a minimal database dump using that format...which eleviates the need for any database...very cool.

Once the other changes are made we can remove this.

Owen Barton’s picture

Title: Generate minimal SQLite environment and use to install Drupal in full environment » Generate minimal mocked or SQLite environment and use to install Drupal in full environment
Issue tags: -Needs usability review +Framework Initiative
FileSize
24.67 KB

So I just did some experimentation, and succeeded in feeding Drupal just enough dummy data (via hard coded arrays) to allow it to bootstrap and serve a (blank, but themed) page.

Disclaimer: just in case it is not clear, this is NOT a proposal patch, but rather an expeditionary attempt to get a sense of scope on what this would need in terms of changes. I made the changes at the place of the database calls, since that was an easier place to see what was going on - this is not intended to AT ALL reflect the place where we would actually want to do the work! I did experiment with putting the queries in a database driver, but there were various challenges with mocking everything when we have no actual connection, and passing back query data in the right structure - it could still work (as a temporary measure, until we can separate out the most minimal framework from DB dependence), but I think it would be a fair amount of work to get going. Note that we use the blackhole cache engine the installer uses.

Overall I think this is looking like a pretty workable approach - here is how I would think we could approach this without needing to inject query results:
- variables: we need to ensure they all have working defaults, and skip trying to load them if we have no DB available
- registry: we need some way to collect defaults and use those if the db is not available (should be easier when CMI lands)
- lock: we need to make this pluggable, and make a blackhole version (same as cache-install.inc)
- menu: this is the most clunky piece right now - however I think WSCCI should be pluggable enough we can replace with a trivial router that just says "no db? call install_page function".
- system: we can rejig the logic so that if no database is available it rebuilds the system array from the filesystem on each request.
- node & user: ideally these dependencies can go away (in the meantime, the node query should go away if we set to something else, IIRC).

As you can see, many of these tasks line up nicely with #1224666: [meta] Unofficial Drupal 8 Framework initiative, and I think this has a lot of architectural benefits (in terms of ensuring subsystems are adequately independent). This also has the potential to simplify code beyond just the installer - such as the maintenance page and the system to serve cached pages without a database connection, for example.

Obviously all of the above will take some time, so we may want to use some of the "array injection" approaches in the meantime (cleaned up appropriately, of course). This would allow us to try connecting it to the installer GUI and hacking out all the redundant code.

moshe weitzman’s picture

Great work, Owen. Your phased in approach sounds good.

Let's hack on this during BADCamp. Core Dev Summit would be a great place to show this around.

boombatower’s picture

#1317528: Separate the testbot from the installer should help, since it will allow changes to installer to be tested. Also had Dries sign off on SQLite approach during BADCamp.

boombatower’s picture

Currently running the file in #10 results in:

Fatal error: Class 'DrupalCacheArray' not found in /home/boombatower/software/drupal-8/includes/theme.inc on line 349

Which is new, looks like some caching changes broke things. I'll probably go ahead and dig into this along with cleaning things up now that the approach has been approved.

boombatower’s picture

Got things working last night, I hope to document what is currently required for minimal installation for future disentanglement. Trying to rethink the workflow of the underlying code and how we redirect to install.php, etc.

My thought is to have two primary functions involved in the process:
drupal_install_min()
drupal_install()

The _min() will probably live in install.php or somesuch since it is intended to be temporary (and should get smaller over-time). Everything in install module will be intended for final release so it will include drupal_install() [renamed from install_drupal() since that seems more consistent].

My basic notes that I am working from.

visit /
- no database?
- generate
- redirect to /install

visit /install.php
- no database for this sitealias
- confirm you want to install in new site alias?
- generate
- redirect to /install

two phase install
- drupal_install()
  - generate min
  - perform install

- web
  - generate min
  - walk through wizard
  - perform install

Seems like we could get rid of install.php since we don't need it as a router replacement for index.php. Only thing holding us back is being able to install into a non-default sitealias. We could change the sitealias code to be more strict that way we could assume if sites dir and settings.php but no database then we just install.

boombatower’s picture

I got things cleaned up to where I am happy with the approach and seems clean. I worked out a number of issues with the workflow such as frying an existing site by running install and having it generate a minimal environment and overriding the settings.php effectively orphaning the real database. Something like that could occur when you attempt to install a new site alias, but don't configure it properly so it falls back to default. I do not want any checks to run before sqlite temp db since we are going to get rid of the SQLite stuff entirely down the road.

So everything in install module should do requirements checking etc. The sqlite stuff will eventually be removed when Drupal can run as a "framework" and the install module will run on top of that instead.

To summarize what the patch does:
1) /install.php - creates sqlite database in temp directory
-- end first http request --
2) redirects to install/wizard (can change, but /install seems to goto install.php which would be a loop)
3) bootstraps sees no database and checks for temp sqlite, finds it and sets as active db
4) bootstrap continues and install/wizard is loaded out of install module
-- end patch --
5) walk through wizard
6) install drupal using parameters from wizard

So the patch provides the entire framework, so moving the form arrays into the module, adding some handling code and then calling drupal_install(). drupal_install() will then be completely independent of form based wizard (as it should be) which allows for the array structure to be cleaner and then when called directly (aka from say drush cli) everything still works nicely.

I get the feeling we will need to do some things before the final installation step (at least old wizard did)...so we made to need to take a look at that stuff. In addition there are a few places in core that seem to check if during install which we should be able to remove. Other stuff like get_t() should be able to go away, but we can do that stuff in subsequent patches.

We also can decide what theme we want to use...this patch uses bartik, but it is super simple to switch.

I managed to get actually sqlite installation part ~60 lines which I am very happy with. Not ready for bot yet, so I'm going to leave as active.

boombatower’s picture

I created sandbox to track work on this, since I don't want to deal with diffing patches. I will be sprinting on this tomorrow at BADCamp sprint so come see me, or IRC, and we can work out of sandbox.

http://drupal.org/sandbox/boombatower/1318364

David_Rothstein’s picture

boombatower’s picture

Saw that earlier today, definitely seems like the same approach/idea just now we have a better way to do it.

cosmicdreams’s picture

boombatower, David et all:

I'd love to work with you folks to revamp the installer based on these principals. Letharion and I, well mostly letharion, have been trying to write the installer as a Symfony 2 application. Where I'm blocked is my lack of understanding of the current installer.

On my todo list is to read through and understand this issue. Is there sometime you all would want to get together to discuss the relevant issues?

boombatower’s picture

Sure, I'll be around most of Friday

David_Rothstein’s picture

I'll be around on Friday (on IRC) and at least semi-available, although not 100% available. Feel free to ping me at any rate, though!

chx’s picture

This might be obsolete in favor of using CMI instead. We had a discussion on Skype and arrived to the conclusion that by now the installer is mostly standard code just has some truly awful setup code and the first steps will be #1730566: Explore using config to unhardwire list of things loaded on install here. Also, the fact that drupal_rewrite_settings is horrific ugly and limited is simply not in scope.

Please feel free to show me otherwise.

Letharion’s picture

@cosmicdreams Great of you to find this issue as well. :) I can't on friday, though I would to talk installer during Münich.

It's not like I have a great deal of understanding on the current installer either to be honest, I just went with the code Crell has started and hacked away.

cweagans’s picture

Okay, so I'd like to resurrect this issue. Since this issue was opened, times have changed and most (if not all) hosting providers support SQLite out of the box. Here are seven major hosting providers that support sqlite and data supporting it:

In talking to chx over the past couple days, I think that we should ship with a minimal, functioning, read-only environment with SQLite. This would essentially be a full-fledged Drupal installation that is capable of installing another Drupal site. This functionality can be provided by a module (hidden, out of the box, but could be un-hidden to allow things like Buzzr or Drupal Gardens to install other sites). This is essentially Aegir in core...sort of.

moshe weitzman’s picture

Status: Active » Closed (duplicate)

Lets not redo the simpletest mistake. We can have a separate app that installs Drupal but that separate app should not be Drupal. I think #1530756: [meta] Use a proper kernel for the installer is working on this. Tentatively marking this as a dupe but please reopen if I am wrong.

sun’s picture

Agreed with @moshe.

#1530756: [meta] Use a proper kernel for the installer will eliminate a ton of the special-casing already by turning the installer into a standalone micro-application, so I don't really see what still applies/remains of this issue here in light of that.

I've the impression that a dozen of people in this issue are having a dozen of different goals and interests, which actually have different technical requirements, each, and half of them are obsolete with aforementioned issue already.

In turn, there's nothing that is actionable here.

I think this needs clarification, and we very potentially need to split out the more concrete change proposals into dedicated issues.

sun’s picture

That said, my own interest in this is obsolete; I'm turning run-tests.sh into an independent shell script in:
#1808220: Remove run-tests.sh dependency on existing/installed parent site

cweagans’s picture

Assigned: boombatower » Unassigned
Status: Closed (duplicate) » Active

Before I re-opened this, I talked to letharion. Let's not close this quite yet, as letharion and I are evaluating it still. Also, this is not exactly a duplicate. The advantage of shipping with a sqlite database is that the installer just becomes a Drupal module that anyone can hack on. A separate symfony app still has the installer partitioned away from the rest of Drupal (and any sense of sanity).

I'm reopening this pending more discussion.

sun’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)

It is very unlikely that #1530756: [meta] Use a proper kernel for the installer will actually end up with a completely separate and external micro app (based on Symfony), because the installer still needs to load and interface with Drupal database drivers and Drupal installation profiles, and install all Drupal extensions, which inherently means that it has to use 90% of Drupal's APIs and services.

From my perspective, the scope of the term "installer micro app" is limited to the (good) idea of using a kernel that is specialized for the installer, which uses proper controllers as well as a set of hard-coded, installer-specific routes.