Making Installation Profiles Awesome

(Side node: does my "include the word awesome" quota include the subject? ;-) )

Overview of awesome: Building installation profiles is currently difficult. Inconsistencies, a lack of documentation, and cumbersome iterative testing results in frustration and overconsumption of caffeinated beverages. This must be awesomed.

Description of awesome:

I recently started using Drupal extensively over the last six months or so. It's awesome and I love working with it. A couple of weeks ago, much to the annoyance of the denizens of #drupal, I started looking into building an installation profile with a bunch of my usual customizations and presets for the various modules I use on more or less every site, be it my own or someone else's. The aforementioned IRC-dweller-annoyance comes from the fact that there's precious little documentation for this fun little jaunt, so I've had to bug 'em with a lot of questions.

The installation profile system is flexible, but that flexibility seems to come at a serious loss of ease-of-use. Does this module want its settings as entries in the {variable} table? Or does it want its configuration data stored as an array? If it's an array, what keys are used? And how are they used? How about adding a view to the system (not hard, but potentially tricky - are there dependency issues? what about potential configuration problems?)?

My idea for GSoC 2009 is to build an application, either online or offline (each has its advantages), to generate this installation profile. I'd envision the workflow to look a little like this:

• Present a list of modules to the user (everything with a supported build for 6.x, say). The user picks what they want enabled. Do dependency checking so required modules are also included. Order modules to satisfy dependencies (or just make the user do it).
• Present the configuration options for core, as well as for all selected modules. The user preconfigures all modules all nice-like, or clicks "use defaults" when they don't want to fiddle with it.
• For modules where you have to create items (ImageCache presets, Views, Panels, etc.), the user specifies the stuff to be loaded in at the start. (Now that I think about it, doing anything significant with Views or Panels might be difficult, aside from "copy and paste an exported spec".)
• The user can load in nodes (pages, etc.), generate URL aliases if Pathauto is included, and build menus to link it all together. (This step and the last might need to be merged--it's awfully hard to build a Panel that slurps in a node if that node hasn't been added yet, for example.)

This isn't a complete list and I'm sure I'm forgetting some stuff, but it's a start--I think the general idea is pretty clear. Obviously some of this would require participation from module developers (maybe a better import API for Views, cough cough); the above is playing pie-in-the-sky a little on that front.

There's some other fun stuff that could be done, too, and streamline a lot of the maintenance of installation profiles. The automated profile builder could, for example, build an "independent profile", which doesn't need to be packaged with a complete installation like Prosepoint or whatever. Instead, it includes the code necessary to bootstrap the profile from a base Drupal build. An independent profile could, during the installation process, get the latest supported versions of any specified module or theme if one doesn't currently exist (I don't know if functionality for this exists on drupal.org at present, but if it does it could be leveraged) and unpack them into the correct places. Instead of tossing around full-size Drupal builds for a given installation profile, now you're downloading a single text file and letting the system handle the rest.

Why is this awesome:

First, a little bit about me: I participated in GSoC in 2007 and 2008. Both years my project focused on usability, on lowering the barriers to entry to hit the ground running with open source software. In 2007, I was tasked with writing the framework for a package manager for Windows, to allow for easier deployment of open source software (just get people to download the conduit, the reasoning went, and they can grab whatever open-source software they like). In 2008, I wrote a set of tools that integrated with Visual Studio to ease use of the Mono Framework and testing on Linux.

This idea's similar in principle: lower the barrier of entry so people get interested and get hooked on Drupal. With a system like this (especially if it included that independent profile bit mentioned above), it would be relatively easy to quickly create quality profiles. And, perhaps more importantly, it'd be easier to get new people into Drupal because the preset profiles just work. You want a quick blog? Download simpleblog.profile, which sets it up as a single-user blog. You want a brochureware site? Download brochureware.profile, which uses panels for a cool-looking layout and drops in a low-key theme. Right now, Drupal has a reputation for being crazy-powerful and also being mean and a huge pain to learn at first. I know that when I first started with Drupal, I went to look at the preconfigured installation profiles, and was disappointed--instead of being able to see a quality working site right off the bat or being able to hit the ground running with a site that was mostly configured the way I liked it, I found out I'd have to start completely from scratch. I got over that hump--the second time I tried to learn Drupal, the first I got confused and quit--and absolutely love Drupal now, but that's not the case for everyone who encounters it. It's easier to just say screw-it and go find something a little easier to start with, y'know?

All in all, I think it's a tool that would provide some pretty considerable benefits in the adoption and ease-of-use areas. One might even call it awesome. ;-)

Mentors:

• ?

Difficulty: Medium when it comes to writing the code, but Hard in terms of length/duration. It may be more than can be done during GSoC. (If I was chosen, I might try to make it my Senior Capstone project for my degree program, which would keep me on the project through May of 2010, at the least.)