Decouple system module from the installer

Not able to access the referenced sandbox project currently, but in general, +1

http://drupal.org/project/environment_modules

subscribe, discussing with catch in IRC.

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 proposal in #11 sounds interesting, but I think it deserves a separate discussion and follow-up issue. There are many more detailed questions involved with it (such as general availability of sqlite on all platforms), which do not have to be answered for the rather simple split and separation being proposed in this issue.

@catch: I'd also suggest to move the removal of $fixed_list into a separate issue. That only looks "related" and like a possible benefit from doing this to me, but it has the potential to block this entire patch.

Created #1226380: Generate minimal mocked or SQLite environment and use to install Drupal in full environment

Subscribing. Note that for this part of the patch:

-  $module_list['system']['filename'] = 'modules/system/system.module';
-  $module_list['user']['filename'] = 'modules/user/user.module';
-  module_list(TRUE, FALSE, FALSE, $module_list);
-  drupal_load('module', 'system');
-  drupal_load('module', 'user');

I had some code at #782672: Loosen the coupling between the user module and the installer/maintenance theme a while ago that tried to get rid of the 'user' part of that only. It may make sense to tackle that independently, since there were a couple of tricks to that (though overall much simpler to deal with than removing the dependency on 'system').

Most of this is obsolete.

The primary remaining dependency on System module are the stream wrappers that it registers; i.e., public://

now seems this one could be closed as obsolete

The primary remaining dependency on System module are the stream wrappers that it registers; i.e., public://

The topic of stream wrappers is attacked in #2028109: Convert hook_stream_wrappers() to tagged services.

Some further aspects remain (such as system_requirements() and system_schema()), but those are equally complex topics like stream wrappers and need to be addressed individually, and this meta-ish issue doesn't really contribute towards solving them.

Therefore, closing this issue - as "duplicate" (of many others).