[development] drupal install
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
> 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
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development