"Don't want your stinking hook"

A few days ago, Michelle blogged to announce Author Pane (a glue module) and took that occasion to complain about the circumstances that made it necessary.

In a nutshell: Some modules could work very well together, if only one of them contained the required hook implementation. Nobody felt up to putting the code into their module.

Finally, I had enough. [...] So, grudgingly, I decided the only way out of this was to create a third module.

I experienced something vaguely similar a while back with a contrib module of my own, DHTML Menu, although that case hinged more on a conflict between two modules (I18n Menu) than on a glue feature.

It is a big logical leap to generalize from two occurrences to a trend, as the system has obviously worked for years. Still I can't help but theorize that this has a common cause: As long as modules work on their own to extend core, everyone knows where they stand, but try to get them to work together, and the development process hits a dead end: Where should the code go?

Neither developer wants to implement someone else's hooks if they're not directly dependent on the module. It's not simply some stupid ego issue ("Why should MY mighty module code for YOUR lousy module's API?"), but a problem of (plainly speaking) convenience. Drupal APIs are fast-changing, and contrib is even worse than core. Implement an API today, and you get to re-implement it tomorrow. Not something developers happily volunteer for. Nobody wants to have to acknowledge another module's existence in their own code - especially a module only tangentially related to theirs, or one they don't use themselves ("scratch your own itch").

The easy solution here is to make a glue module that implements both, but this module still needs to go somewhere specific: Do you put it into one of the two existing projects (which)? Or do you have to clutter the project namespace (as here) with a separate project that contains only glue code?

I can only conclude that the infinitely extensible modularity of Drupal works great on the code and usability side, but clashes with the "project ownership" mentality on Drupal.org. Perhaps it would help to open up sub-module creation to all developers (in the form of a "contrib" folder in every project to imitate "translations")? Or perhaps such things just have to be decided in face-to-face meetings at Drupalcon: "Heads says I implement the hook, tails you" :D .

News Category: 

Comments

I've calmed down since writing that so I'm not so angry but it still is a problem without a solution. In my case, there are some plusses. The Author Pane module turns out to have some limited use outside of my modules which just needs a bit of documenting to explain. And it removed some code duplication as well. But there still remains the problem that I am implementing hooks on behalf of a growing number of other modules with all the potential problems associated with that.

Unfortunately, I don't have a good solution for this. You can't force maintainers to work together. I try to be helpful and am willing to add things to make my modules play nicer with other modules but there may come a day where I say no, I don't want that in my module. And what then?

All I know is I don't want it decided at Drupalcons... I'm a long ways from getting to go to one of those. ;)

Michelle

Well designed APIs can alleviate this, somewhat, as long as both modules have well designed APIs.

For one, the more your module offers an API to other modules, the more use people might find for the module. Often APIs can be used simply by people adding functionality to their module to make it suitable for their site. This is a plus. For two, it makes it friendlier to other modules who actually want your functionality.

For modules whose maintainer doesn't, it is helpful to have the API work completely standalone. Especially if your API can do version checking, so that if the API changes, the other contrib module doesn't actually break, but instead that piece of functionality merely stops working. If your API is strong enough, any reasonably competent user who wanted that functionality should be able to help patch in an update. This lowers the maintenance hassle for everyone, except the person who actually had to write a really good API for all this to work.

These are the rules I've learned:

1) The more important your module is, the more likely other modules are willing to support your API.
2) If the code that utilizes your API can be standalone, it's a lot easier to get it accepted.
3) If the code that utilizes your API can auto-deactivate when the API changes, guaranteeing fewer future headaches, it is a lot easier to get it accepted.
4) If your API is accessible and well documented, then it will scare people unfamiliar with it the least.
5) If your patch won't be accepted, but it's really useful, then it's time for a glue module. Find someone who really wants the feature to co-maintain it.

All I know is I don't want it decided at Drupalcons... I'm a long ways from getting to go to one of those. ;)

I've never been at one either! :)

Well, I can't speak for anyone else but the API that I was asking people to use is the template preprocess system built into Drupal core. So hopefully that wasn't too scary. ;)

As for module popularity, mine aren't up there with views by any stretch but they are used by quite a few people. Advanced Forum, at least, is one that you'd think people who write forum related modules would want to integrate with. *shrug*

Michelle

Perhaps it would help to open up sub-module creation to all developers (in the form of a "contrib" folder in every project to imitate "translations")?

Please, 1,000x no. We had this in the Organic Groups queue project for awhile. Inevitably what happens is people start logging issues against the main project, since that's where they downloaded the code. And since the original module contributor has since moved on to other clients, they never come back to deal with these, so it falls to the "main" module maintainer to not only be an expert in their own code, but any other janky code that someone else contributes as well. No thanks.

While I am willing to work with other maintainers to make my module work with theirs, I definitely don't want a free for all commit area in my module that I'd have to keep up with. I don't even like that translators can commit directly, though at least that isn't something I need to worry about too much.

Michelle

What about making the contrib part on d.o hierarchical? Submodules go under /project/module/submodule, get their own maintainer and issue queue. No name space clutter, issues go where they belong to.

Submodule developers could do some sort of registration to which part of the parent module their submodule refers. The accuracy of the description is the submodules maintainers responsibility.

The parent module's maintainer gets a list of these references and therefore knows about dependencies without having to look at the submodule's code.

If the parent module's maintainer changes (or better is about to change) his module in a way that affects one of the submodules he just needs to set a flag in the aforementioned list with an optional hint about the changes. This gets sent to the submodule's maintainer. The flag could also be shown on the submodule's project page to inform potential users about the incompatibility. Users of the affected submodule may get information in a way similar to the list of available updates.

That way it is clear who is responsible for what (his own code) and with only a little extra effort on both sides it would be much easier for modules to play nicely together.

I'd file that as feature request on d.o or g.d.o but I'm not sure where the right place is.

The problem still remains that submodules are often overkill. By way of example, here is one of the functions I requested to have added to a module:

<?php
/**
 * Implementation of hook_preprocess_author_pane().
 */
function fasttoggle_preprocess_author_pane(&$variables) {
  
// The full user object for the author
  
$account $variables[&#039;account&#039;];

  
$variables[&#039;fasttoggle_block_author&#039;] = theme(&#039;links&#039;, 
fasttoggle_link(&#039;user&#039;, $account), array(&#039;class&#039; => &#039;links inline&#039;));
}
?>

That's it. Basically 2 lines outside of comments and the function declaration. Is that really worth making a module, even a "submodule"? Keep in mind that modules need to be enabled by the site admin. Author Pane is up to 10 module integrations, now. That's 10 submodules that would need to be downloaded and enabled on top of the 10 modules that the submodules are for.

I think this is more of a social problem than a technical one. The "not in my module" attitude is strong. Couple that with the "I don't really maintain my module" epidemic and you end up with what I struggled with for two months.

Michelle

No, it's just the amount of work you have to do to get what you want. Overkill would be to have to convince all the other module maintainers to accept your patch.

I had a similar issue with Domain Access (http://drupal.org/project/domain) -- specifically, hook implementations that allow for different module settings per domain. There is an internal hook for this (the inelegantly named hook_domainconf()), that other module authors didn't see the need to support.

So what I did was to allow the creation of a domain_conf.inc file (not provided in the module download) that could be used to implement this hook for other modules. If this file is present, it is loaded automatically by the parent module.

See domain_conf_init() in http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/domain/domain_conf/domain_conf.module?revision=1.31&view=markup for the way to make this work.

See http://drupal.org/node/236877 for the discussion that led to this approach.

© 2006-2012: All content, unless otherwise noted, is the property of Arancaytar. It may be copied and modified with attribution for non-commercial purposes. By publishing comments on this site, you grant Arancaytar a non-exclusive, perpetual license to reproduce and publish these comments along with any identifying information provided. (You may request your comments to be deleted or edited voluntarily.)