Hey, A few years ago, most module projects hosted on drupal.org had one module in them, but nowadays more and more projects pop up with more modules in there. Examples include ubercart, ecommerce, views, ad.module and so on. Because module naming and placement guidelines are missing (as far as I know), we have various naming conventions. These projects have multiple modules, but their "root" module (ie. the module required by all or close to all submodules) is put in different places: - views/views.module (all other modules in the same folder (1)) - ad/ad.module (submodules in subfolders (2)) - ubercart/uc_cart/uc_cart.module (other modules up one folder (3)) - ecommerce/ec_common/ec_common.module (other modules up one folder (3)) These are at least three different methods to do it: - (1) all modules it he same folder - (2) root module in root folder, submodules in subfolders - (3) root module in some subfolder, other modules alike As the complexity of a package increases, module organization goes down this route. For a few files, the same directory works, when the root module only has a few files, it could still stay in the root directory, while submodules go to subfolders, and at the end the root module gets complex (images, include files, CSS files) and it goes down to it's own folder. While all modules might not go through this route, you get the idea. In any case, there is also no guarantee that the "root module" is named after the project. 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. My use case is when we generate translation templates or export translations for Drupal 6, the system looks under the module directories 'translations' subfolder to import .po files automatically. So common strings (shared by the submodules) should be saved in one .po file under the module you would surely enable in all cases. So we need to export the common strings to the translations subdirectory of the "root" module. We need to know about the root module. The (1) organization also has a few unwanted side effects, but they are not as pressing as not knowing about the "root" module at all. Frankly I have no cool idea to go about this, but it should be done for sure. A new .info file key might be in order to mark base modules or required modules. Or we can go in and compute a dependency tree with the requirements and identify the root module ourselfs. This obviously only works if the dependencies are properly marked, and is definitely not how it works with Drupal itself, where modules just does not depend on system module. At the end *for my use case* the ideal world would look like (2) with the root module always named after the project name, but this is probably not going to happen, so let's think about other solutions. Gabor