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. http://www.drupal.org/install-system-overview
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 duplication.
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 easily. 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