Installation -- Can A Module "Refuse" To Be Installed?
I've started to write .install files for the modules I'm responsible for. Mostly this is pretty straightforward. But there are a few areas I'm hoping there is support for in the system: * UI for problems/status during install: I've made it a practice to do like merlinofchaos and put up a message to indicate I've installed tables (with a call to drupal_set_message). It's less clear what's best to call if there's a problem. * I've noticed that there are calls in install.inc to register schema versions, but I haven't seen any examples of their being used. How *should* those functions be used? * Dependencies are an issue for some of the stuff I'm installing. It would be a good thing if the .install could detect that a needed module was not present, and in that case, put up an error message and refuse to install. Is there a mechanism to do this currently? Thanks, Rob Rob Thorne Torenware Networks
Rob Thorne wrote:
I've started to write .install files for the modules I'm responsible for. Mostly this is pretty straightforward. But there are a few areas I'm hoping there is support for in the system:
* UI for problems/status during install: I've made it a practice to do like merlinofchaos and put up a message to indicate I've installed tables (with a call to drupal_set_message). It's less clear what's best to call if there's a problem. * I've noticed that there are calls in install.inc to register schema versions, but I haven't seen any examples of their being used. How *should* those functions be used? * Dependencies are an issue for some of the stuff I'm installing. It would be a good thing if the .install could detect that a needed module was not present, and in that case, put up an error message and refuse to install. Is there a mechanism to do this currently?
cut & paste cause I lazy /** * hunmonk's module dependency check: see http://drupal.org/node/54463 */ function views_ui_form_alter($form_id, &$form) { if ($form_id == 'system_modules' && !$_POST) { views_ui_system_module_validate($form); } } /** * hunmonk's module dependency check: see http://drupal.org/node/54463 */ function views_ui_system_module_validate(&$form) { $module = 'views_ui'; $dependencies = array('views'); foreach ($dependencies as $dependency) { if (!in_array($dependency, $form['status']['#default_value'])) { $missing_dependency = TRUE; $missing_dependency_list[] = $dependency; } } if (in_array($module, $form['status']['#default_value']) && isset($missing_dependency)) { db_query("UPDATE {system} SET status = 0 WHERE type = 'module' AND name = '%s'", $module); $key = array_search($module, $form['status']['#default_value']); unset($form['status']['#default_value'][$key]); drupal_set_message(t('The module %module was deactivated--it requires the following disabled/non-existant modules to function properly: %dependencies', array('%module' => $module, '%dependencies' => implode(', ', $missing_dependency_list))), 'error'); } }
* Dependencies are an issue for some of the stuff I'm installing. It would be a good thing if the .install could detect that a needed module was not present, and in that case, put up an error message and refuse to install. Is there a mechanism to do this currently?
Based on code Chad (hunmunk) posted, I've drafted a Dependencies module, http://drupal.org/node/57071, that tests for dependencies and doesn't allow modules to be installed if their dependencies are missing. You could include a _dependencies() hook, e.g. modulename_dependencies() { return array('module1', 'module2'); } Of course, that will work only if a site has the Dependencies module installed and enabled. Or else feel free to just add your dependencies to the default array in the dependencies/dependencies.module (this goes for any other module developer). Robert Douglass suggested, and I concur, that it woud be useful to distinguish between hard and soft dependencies, but I haven't yet incorporated his suggestion into the module. Nedjo
Well, I appreciate someone is finally thinking about dependencies. I had a look at Nedjo's code, here are some questions: 0) Do you handle module versions? I don't see anything in the code. How do i say, "I depend on moduleA versions > 10, but not more than 15" 1) How is an upgrade handled? Say module A required module B on install. Does it again require it during upgrade, or can the module be missing? (think "import" modules vs "actual" modules) 2) The code auto-disables stuff; which is dangerous. I would provide an additional disable hook for the faulty module to recover from problems before being killed. Say we had a spam-clean.module, depending on search.module for finding to clean nodes. Now an admin accidentally disables search.module because spam bots are wreaking havoc, and this disables spam-clean, which foobars the website. A good place to look for inspiration is APT, instead of reinventing the wheel. http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html (I think i've mentioned this before when the topic came up) -Arnab On 4/8/06, Nedjo Rogers <nedjo@islandnet.com> wrote:
* Dependencies are an issue for some of the stuff I'm installing. It would be a good thing if the .install could detect that a needed module was not present, and in that case, put up an error message and refuse to install. Is there a mechanism to do this currently?
Based on code Chad (hunmunk) posted, I've drafted a Dependencies module, http://drupal.org/node/57071, that tests for dependencies and doesn't allow modules to be installed if their dependencies are missing. You could include a _dependencies() hook, e.g.
modulename_dependencies() { return array('module1', 'module2'); }
Of course, that will work only if a site has the Dependencies module installed and enabled.
Or else feel free to just add your dependencies to the default array in the dependencies/dependencies.module (this goes for any other module developer).
Robert Douglass suggested, and I concur, that it woud be useful to distinguish between hard and soft dependencies, but I haven't yet incorporated his suggestion into the module.
Nedjo
Arnab Nandi wrote:
Well, I appreciate someone is finally thinking about dependencies.
There are at least two other proposed dependency systems with code out there already actually. I listed them awhile back at http://www.oscms-summit.org/events/install-dependencies. People have been thinking about this. -- Neil Drumm http://delocalizedham.com/
Nedjo Rogers wrote:
Based on code Chad (hunmunk) posted, I've drafted a Dependencies module, http://drupal.org/node/57071, that tests for dependencies and doesn't allow modules to be installed if their dependencies are missing. You could include a _dependencies() hook, e.g.
I see dependencies as something that is clearly core functionality once someone takes on implementing it. I would not want to add another required core module for dependencies because: - That would create another line on an already long .../admin/modules page which most people will simply not want to care about. - I fear layering on the formapi extensibility will make code more fragile (what happens when two modules try modifying the same elements) and harder to understand. I'd like to see development on this move forward as a patch to system.module. What might be "holding back" core dependencies? First, I do think dependencies will be an inevidable step, so we need to get it done at some point and do it right. The potential problem I see is the potential for intricate dependency trees between contrib modules and putting users in dependency hell. Imagine what would happen if each ecommerce module were in its own directory and a dependency system was relied upon. -- Neil Drumm http://delocalizedham.com/
Neil wrote:
I see dependencies as something that is clearly core functionality once someone takes on implementing it. I would not want to add another required core module for dependencies
Fully agreed. I threw together the dependencies.module mainly to see if we could avoid having each module in 4.7 adding its own handling. Over the weekend Adrian agreed to take over maintainance. We've eliminated the idea of a dependencies hook, looking instead to metadata files. The idea is putting in place a 4.7 solution that pilots approaches for core.
I see dependencies as something that is clearly core functionality once someone takes on implementing it.
Like http://drupal.org/node/18447 ?
I have taken over control of the dependencies module, and will be putting the code together, in contrib (god bless _form_alter) to handle the dependency checking / metadata loading. Really, a good chunk of this is ready and tested, it's just assembling it in one place. Before 4.7 and the forms API, this meant modifying system.module, but that is not the case anymore. This will become a patch for system.module, but not until the 4.8 branch is available, additionally a lot of people want to use this today (see: ecommerce) I've already discussed with Jeremy the possibility of including this with the civicspace installer build, so we can get a good amount of testing for it, perhaps even a semi-official uptake of the meta-info files in contrib during 4.7. Vlado has a script which generates meta-data files for all the modules in contrib, but they do need some hand tweaking however, so moving to using meta-data isn't even going to be that hard. On 10 Apr 2006, at 8:02 PM, Neil Drumm wrote:
- That would create another line on an already long .../admin/ modules page which most people will simply not want to care about. Of course not. This is just to get the code developed, and deployed, so we can get it fast tracked into 4.8 when it opens.
- I fear layering on the formapi extensibility will make code more fragile (what happens when two modules try modifying the same elements) and harder to understand. It's a means to an end, and it's really just additional validation on a form. That's why we have the possibility of multiple validation hooks in the first place.
I would like to have it be as non-obtrusive as possible. Perhaps even just failing validation of the form, and adding a new checkbox to the top saying 'the following modules were required, would you like to enable them too?'. or a message stating that the module couldn't be enabled as the required modules weren't found. Perhaps even do a little bit of javascript that asks you whether you want to enable all the dependencies, so you don't have to do it in multiple phases if you miss something.
I'd like to see development on this move forward as a patch to system.module. That's definitely the plan. The meta-data info could also be used to build the admin/modules screen to stop memory problems, for instance.
We can look at these more serious architectural changes for the next release.
What might be "holding back" core dependencies Nothing. Except no 4.8 branch, and stuff (like ecommerce) really needing it today.
The potential problem I see is the potential for intricate dependency trees between contrib modules and putting users in dependency hell. Imagine what would happen if each ecommerce module were in its own directory and a dependency system was relied upon. Intricate dependency trees likely already exist between contrib modules, except apart from help text, we have no way of documenting or checking it.
Being able to mark conflicting modules, and the like would also be very useful. And the modules can be in a tree, or in their own directories, but thanks to the great equaliser of system_listing, it's all a flat list to us. if we are talking about packaging them separately, that's a discussion we should have at a later stage, when we have a working simple dependency system with well tested version checking, INCLUDING having chosen a standard format for individual package versioning (http:// drupal.org/node/58066) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
* I've noticed that there are calls in install.inc to register schema versions, but I haven't seen any examples of their being used. How *should* those functions be used?
You shouldn't. Hook_install is invoked when a module is enabled for the first time. Right before that, the schema version is set to the latest update number in install.inc (or 0 if there are none). Then later, when updates are added, update.php will pick them up and autoselect the right version. So the first update should start with version 1.be Steven Wittens
Hook_install is invoked when a module is enabled for the first time. Right before that, the schema version is set to the latest update number in install.inc (or 0 if there are none).
That should be "yourmodule.install" rather than "install.inc". Steven
Steven, If I am understanding you correctly, perhaps you would be a bit more explicit: where does "latest update number" get set? I suspect you mean that the install code is looking for functions with signatures like "mymodule_update_42"; you are saying that if there is a "mymodule_update_41", but no number higher than "42", then the update number will be "42". I am asking this because if this behavior is documented, the documentation is well hidden, and for the record, I'd like somebody to point to where this is documented, so that others can actually find it in future. Rob Steven Wittens wrote:
* I've noticed that there are calls in install.inc to register schema versions, but I haven't seen any examples of their being used. How *should* those functions be used?
You shouldn't.
Hook_install is invoked when a module is enabled for the first time. Right before that, the schema version is set to the latest update number in install.inc (or 0 if there are none).
Then later, when updates are added, update.php will pick them up and autoselect the right version. So the first update should start with version 1.be
Steven Wittens
Rob Thorne wrote:
Steven,
If I am understanding you correctly, perhaps you would be a bit more explicit: where does "latest update number" get set?
I suspect you mean that the install code is looking for functions with signatures like "mymodule_update_42"; you are saying that if there is a "mymodule_update_41", but no number higher than "42", then the update number will be "42".
I am asking this because if this behavior is documented, the documentation is well hidden, and for the record, I'd like somebody to point to where this is documented, so that others can actually find it in future.
Rob
Rob - your example is a bit ambigous. If the las defined update is mymodule_update_41 then the updater sets the schema_version to 41 after successful completion. feel free to update http://drupal.org/node/51220
participants (9)
-
Adrian Rossouw -
Arnab Nandi -
Earl Miles -
Karoly Negyesi -
Moshe Weitzman -
Nedjo Rogers -
Neil Drumm -
Rob Thorne -
Steven Wittens