In Drupal 7, Installation profiles should become modules.
Most of the work done now will be done in hook_enable.
The benefits:
- Profiles get to implement hooks
- To build a profile, you don't need to learn a whole new API
- Multiple profiles can be enabled at once. (Imagine a site for a project - you could enable the wiki profile, blog profile, and project profile)
- Profiles can be disabled
- Profiles can have updates
- Profiles can be monitored w/ update.module
Profiles will have a special category in their .info file: Distributions.
Then, they will be shown during the installation process, and on a separate page, admin/build/distributions, and hidden from the system modules page.
(Assuming we'll re-name to distributions).
Comments
+1 on the general concept...
I like that people don't have to learn multiple systems to do this; just re-use everything they know from modules already. And allowing > 1 profile to be done on installation, having revisioned profiles, etc. already addresses many of the existing problems with the install profile system.
Rather than creating another .info file flag, though, I'd personally prefer a 'magic' category like "Distribution" ("profile" has always been an ambiguous term with at least "user profiles" and "profile system performance" so I'd love to see it ditched) that, if found, will treat it like a something.profile file and move it to the front of the list of modules to enable. It might also treat its dependencies[] line as a both a "do these modules exist?" check in order to get past the profile selection screen, and then act as a bunch of module_enable()s after the db credentials have been typed in.
[Edit: incorporated this into main RFC]
Earl voiced concerns over how much we can do in the 'stripped-down' version of core that's present prior to the database layer existing, but we probably won't know until we try.
What does the UI look like for enabling distributions /after/ installation? Are they in a different place than admin/build/modules?
Distributions
Definitely let's take the opportunity to call these distributions, that's much needed IMO.
I think chx has some plans to use sqlite during the installer once PDO is in (and if sqlite can be made a requirement), which'd pretty much allow Drupal to be fully functional as soon as you visit install.php
What about installing profiles on live sites? If distributions can be modules, then I can see it being useful for meta-modules like Advanced Profile/Forum - so you could start with the blog distribution, but later add Advanced Profile down the line.
The UI
They will be (per Dries' request) at admin/build/distributions or profiles. The page will look essentially the same, I would think.
I been waiting for this...
I been waiting for this for ages. It always seemed crazy that you could only have one install profile and only at the install. So, yes, all for this...
I would urge you guys to consider just having a "meta-module" concept that catch suggests rather than the idea of a "distribution" (sorry webchick and catch). "Distribution" sounds like a Linux distribution. A big solid hunk of a thing. Something that you're stuck with at a kernel level. And aren't we more talking about concepts of plugins/modules/packages rather than full on distributions?
But what we are talking about here, conceptually, is almost more of a plugin that can install (?)*, invoke and configure other plugins/modules.
As dmitrig01 says you can add/remove/update these meta-modules at any time and not just at the install time. Brilliant!
The difference between
The difference between distribution and meta-module is that drupal.org will be able to package groups of modules together into one tarball (probably along with core). There are probably use cases for both, so that'd need some though.
Automated upgrade functionality is a summer of code project: http://groups.drupal.org/node/10893
Some thoughts here
So from the install front, as current install profiles go, you would be able to choose as many distributions as you wish, and it would complete all necessary hooks from each one?
And then later the user would be able to enable or disable as many as they want at admin/build/distributions?
I hate to revisit this, but I think distribution may be the wrong word for what we are looking at here. It already strikes me odd that we could support multiple 'distributions' on installation, and support changing the 'distribution' after Drupal is installed. This breaks pretty badly for users who are used to distributions in reference to Linux, and it is not so easily switched afterwards.
I've said it before but I really think that Easy Eclipse got it right with their model. It allows downloading of a distribution up front. Once you've picked one, that it's, that's all you get, although you can add all the plugins to add functionality from other distributions easily.
Anyway this is all best thought out for another issue (at least the name stuff anyway). As for now I am more interested in whether or not this would include the ability to handle multiple distributions at install, and multiples enabled/disabled at a later date?
Distribution vs. install profile
A distribution == core + a set of configuration, themes, contributed modules, and even third party code that make up a task-oriented bundle of a Drupal install.
Yes, there is some terminology work needed. Something that runs not just at install time would be tough to be called an install profile :P I've always liked the concept of packages. Install the wiki package, for instance. And, of course, we can still use distribution, which is made up of one or more packages...
1 for "package"...
+1 for "package": a collection of modules.
Would a package also configure the set of modules it installs?
Could this cause conflicts if the a given module is being used by 2 packages?
package is good
I like package a lot, and I reckon it's packages which would open up install profiles to wider development. I reckon it'd be flexible enough to avoid another round of terminology changes later - we'd have something like this:
Module - one module, possibly with dependent sub-modules (Views, Panels etc.)
Package - several modules + glue (+ theme) - installed at run time
Distribution - package(s) + glue + core - only for install and upgrades
Yes exactly
I think that's the right terminology and break down.
Of course, a package is actually IMPLEMENTED as a module. So, this also both individual modules and packages to use the same concept of "settings" on install. Each module could potentially even ship with some default settings, which a package could override for its specific use case(s).
Keeping it simple
We should make sure the end-user gets the difference between a module, a package and a distribution. We're creating packages and distributions to make it easier for them to use Drupal and getting the terminology as clear as possible is an important step in doing so. Following with the wiki example, it doesn't really matter for the user that the wiki package is the combination of a couple of modules, he just wants to install "it" and start adding wiki pages. I'd definitely offer packages in the modules download pages.
More thoughts
Should distributions/packages/thingies be able to specify dependencies on other packages? If they are based off of a similar system as modules this would be easy, and would also allow dependencies on modules, which would seem to be an obvious need.
Also, I have been thinking about the act of turning of, disabling or uninstalling a distribution/package, would that disable all the modules it uses? It may need a way to check if the modules are in use from another packages, or turned on manually... or maybe disabling a distribution/package wouldn't turn any modules off at all?
Just some more rambling thoughts....