On 10/14/07, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
On 10/14/07, Cog Rusty <cog.rusty@gmail.com> wrote:
Why I investigated this is that I would need a stable solution to indentify these "root" modules in each project. We know this is system module in Drupal itself, but collecting a wired in list of "root" modules for each module suite seems like a bad idea.
You could check the dependency tree: Most to all submodules will depend on the "root" module, so you could determine that one by defining it as "the module where count(is_depended_on) is higher than for all other modules". Of course, that comparison has to be restricted to the root folder of each module collection, for which I don't have a good idea on how to reliably determine it.
Dependencies is not such a reliable way. Independent modules can be of two kinds. Either the main bare-bones module without additional bells and whistles, or auxiliary utility modules which are leaves in the dependencies tree. An example is the ecommerce module where there are at least two modules on which others depend, "store" (which I believe is the main one) and "ec_common", none of which is located in the package's root.
Well, I used "root" modules as the module in the given suite, which should always be enabled, and some of the others depend on it. In this sense ecommerce has two such modules: ec_common and store. The problem is identifying at least one of those, not to pick one from a list if we have more :) I don't think it is a good idea to put these modules actually in the module suite root, even I would advocate module suites to have each module in its own directory , unlike views or cck, but like ecomerce or ubercart. (Although this definitely needs to be decided on a case by case basis, having folders for each module allow more space for them to grow).
Gabor
Sure, I have noticed that you have followed a similar apporach in l10n_server. Regarding identifying them from the dependencies, another counter-example is the privatemsg-5.x-2.x module where the privatemsg.module depends on the included mail_edit.module (which can be enabled independently and is also used by subscriptions-5.x-2.x). Although in this case they are not in directories and the main one is identifiable by its name.