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
Gábor Hojtsy wrote:
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.
There are two pieces of information in the .info file you can use: 1) The 'package' keyword which is not reliable at the moment because enough module authors misuse it that the update_status project has had at least 2 'feature' requests to set its package to 'Administration' even though there are clearly defined rules for that; both of these requests have pointed to other modules that do this incorrectly. 2) The 'project' keyword which is how update_status knows what modules are together. Now, this isn't 100% reliable either because it is placed there by the packaging system; and it doesn't tell you what the root module of the project is, but it can tell you what modules are, at least, all together. update_status does some guessing based upon directory location if the 'project' keyword is missing and it's 99.5% reliable (had a case where it's not reliable in the "best practice" scenario of placing a group of modules under 'contrib' and another group under 'custom'.)
On 10/12/07, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
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
I want to throw-in a related problem to be taken into account. It is about the "human readable names" of the modules. I am looking at the /admin/build/modules page of a "tryout" site, searching on the page for "image" and I find 3 different "Image" modules with their own dependencies. Ad group Image: Enhances the ad module to support banner ads. Depends on: Ad (disabled), Upload (enabled) CCK group: Image: Defines an image field type. Depends on: Content (enabled) Required by: CCK Slideshow (disabled) Image group: CCK slideshow: Depends on Image (enabled) -- ***notice the group*** ... Image: Allows uploading, resizing and viewing of images. Required by: Acidfree (disabled), Flash Gallery (disabled), Image Attach (enabled), Image enhanced scaling (enabled), Image Gallery (enabled), Image Import (disabled), Image assist (enabled), Mailsave to image (disabled), Postcard (disabled), Upload image (disabled), Video Image (disabled) There are several modules which "Depend on Image". The only way to tell which one of the 3 is going to each "Image module" and reading its dependents. I would love to see the "human readable names" disappear.
Cog Rusty wrote:
I would love to see the "human readable names" disappear.
Ugh, no. Module authors just need to be smart enough not to make the human readable names very different from the actual module name. Giving something that isn't 'image.module' the human readable name of 'Image' is basically retarded, since image.module is still a fairly high profile module.
On 10/12/07, Cog Rusty <cog.rusty@gmail.com> wrote:
I want to throw-in a related problem to be taken into account. It is about the "human readable names" of the modules. I am looking at the /admin/build/modules page of a "tryout" site, searching on the page for "image" and I find 3 different "Image" modules with their own dependencies.
Ad group Image: Enhances the ad module to support banner ads. Depends on: Ad (disabled), Upload (enabled)
CCK group: Image: Defines an image field type. Depends on: Content (enabled) Required by: CCK Slideshow (disabled)
Image group: CCK slideshow: Depends on Image (enabled) -- ***notice the group*** ... Image: Allows uploading, resizing and viewing of images. Required by: Acidfree (disabled), Flash Gallery (disabled), Image Attach (enabled), Image enhanced scaling (enabled), Image Gallery (enabled), Image Import (disabled), Image assist (enabled), Mailsave to image (disabled), Postcard (disabled), Upload image (disabled), Video Image (disabled)
There are several modules which "Depend on Image". The only way to tell which one of the 3 is going to each "Image module" and reading its dependents.
I would love to see the "human readable names" disappear.
??? Why not name the modules properly instead? From the list you have above, I would say: - Banner image or ad image - Image field - Image Gabor
Gabor has started a discussion on a subtle point and I think it is best not to introduce "related problems" into the same thread. Lets get back on topic.
I want to throw-in a related problem to be taken into account. It is about the "human readable names" of the modules. I am looking at the
I vote for -- based on experience from both sides, and having used both (1) and (2) -- submodules in subfolders, root module in root folder. Said another way, any module(s) in the module download that depends on the core module gets put in a subfolder. And any module that depends on another module should (of course) list that root module as its 'package.' - Ken RIckard agentrickard On 10/12/07, Moshe Weitzman <weitzman@tejasa.com> wrote:
Gabor has started a discussion on a subtle point and I think it is best not to introduce "related problems" into the same thread. Lets get back on topic.
I want to throw-in a related problem to be taken into account. It is about the "human readable names" of the modules. I am looking at the
On Friday, 12. October 2007, Gábor Hojtsy 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. Also, this only works with projects where all modules are put together into one single folder structure in one single d.o project, whereas it falls down when third-party modules like CCK fields are separate projects.
On 10/14/07, Jakob Petsovits <jpetso@gmx.at> wrote:
On Friday, 12. October 2007, Gábor Hojtsy 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.
Also, this only works with projects where all modules are put together into one single folder structure in one single d.o project, whereas it falls down when third-party modules like CCK fields are separate projects.
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
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.
On Sunday 14 October 2007, Gábor Hojtsy wrote:
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
I would favor a naming convention of foo/foo.module for the "main" module in any tarball. Multi-file components of the module live in foo/foo.key.inc, a la the page split code. Packaged sub-modules, well, I don't like the idea of underscore as a standard because underscore is already heavily overloaded. :-) I don't know of a better alternative, though. In some cases, certainly, they don't need a related name. (We don't need 50 modules named cck_foo.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Quoting Larry Garfield <larry@garfieldtech.com>:
In some cases, certainly, they don't need a related name. (We don't need 50 modules named cck_foo.)
For namespace reasons alone I disagree. If package foo distributes two modules then they should be named foo_bar and foo_baz. Otherwise they need to be separate packages creating separate namespace for each package. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (8)
-
Cog Rusty -
Earl Miles -
Earnie Boyd -
Gábor Hojtsy -
Jakob Petsovits -
Ken Rickard -
Larry Garfield -
Moshe Weitzman