[development] drupal install

Adrian Rossouw adrian at bryght.com
Mon Jan 9 03:14:28 UTC 2006

On 09 Jan 2006, at 3:11 AM, Neil Drumm wrote:

> Stefan wrote:
>> there is something like this on the plate for a long, long time..
>> Adrian Rossouw worked on this till half a year a go, after that i   
>> thouth Neill Drumm proceeded his work. you should contact those  
>> guys,  they are both on this list..
The forms api work was also part of the install system work, it was  
aimed at making workflows (wizards) easier to create.

As such, I believe we can finally get the install system (of which  
drumm already did the upgrade parts) into core for 4.8.

> I haven't actually done much with install itself since I chose to  
> tackle upgrading first. Next up for me is module installation,  
> which will eliminate .(my|pg)sql files. The lack of a module  
> dependency system is more of a problem than not having an  
> installer, chx has an excellent patch for that. Manual installation  
> works and is well documented so it is not the biggest problem right  
> now.
> For installation there are a couple efforts. This is all from  
> memory so please correct and add to the list as needed. It would  
> help a lot in my session planning for Vancouver.

Same project, different aspects.

> CivicSpace's installer, maintained by Ankur. This is very big and  
> has a lot of CivicSpace hard coded in. A lot could be done to  
> remove code duplication with core, but there may be functions which  
> cannot currently be bootstrapped without a database.
I originally wrote the installer for civicspace, and the wizard api I  
designed, but decided not to implement for drupal 4.4 (back in the  
day) is being used for it, primarily because of all the code

Also, the forms API was written to make these wizards easier to  
write, so the install wizard script should be re-evaluated for 4.7.
> Bryght's provisioning system developed by Adrian is closed source.  
> Last I knew CivicSpace was getting a license of some sort for one  
> or two projects which are going to go live real soon now.
All the drupal code is open source, and exists as patches on drupal.org.

The only stuff that is not distributable is the python scripts in the  
backend, and our hosting system / client database schemas.
This system is far from being a generic installer, and is used for  
maintaining large (thousands of sites) installations, cleanly and  

This kind of thing is expressly based on removing any user interface  
and automating as much as possible. For this, .install files (as with  
your upgrade work) are used,
and in fact, you originally got the code from me.

> Vlado is working on a command line installation framework which  
> might be able to be used with other webapps, comparable to apt. I  
> don't know much about that one.
Vlado wrote a generic package dependency system, and scripts which  
inferred a lot of this from module_invoke use.
It still invokes .install files for each of the packages it installs,  
and as such is part of the same solution, not a solution of it's own.

It introduces stuff such as virtual packages, which allows us to very  
easily do install profiles and the like.

> Two related things which are lower priority than an installer are  
> post-installation configuration and site profiles. These two things  
> would be nice to have, but there are existing tasks that aren't  
> going away which can be made better first.
These are two things which are 'free' if we use a proper package  
dependency sytem.

Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com

More information about the development mailing list