Re: [development] Confused: package value of info files
-----Original Message----- From: development-bounces@drupal.org [mailto:development- Subject: Re: [development] Confused: package value of info files
Quoting Morbus Iff <morbus@disobey.com>:
experience if the user has more than a handful of "Other" modules. Shouldn't the user see a grouping for Taxonomy for all of the modules dealing with Taxonomy?
No, because that is a category. That is not a package. Please see the archives of the development list for an already extensive discussion of this, specifically my own message here, which inspired this docs:
To you it is a package but to the end user looking at the menu it is a category or package grouping; a module is a package; more than one module focused on extending the same function is a package group. The end user experience is what matters, not the dev types that know what it is supposed to represent.
What? This is set to help end user experience. One end users needs are not another's. Too many discrete groupings only serve to confuse and dilute the usefulness of the feature. In any given install there are very very few groupings of modules that will work and play well together in such a grouping. Dismissing the community experience and the very long discussions we've had planning this as 'merely dev type opinions' is not a correct thing to say. We have had serious participation form coders, UI folks, end users non-coders, support types, etc.
http://lists.drupal.org/pipermail/development/2006-November/021080.html
Yes, I have read your technical explanation before. It is the end user experience I am trying to benefit. I agree that a module in a package, package grouping, category or what ever it is needs to move to Other if there is only one in the grouping installed in the users environment. I disagree that if I have more than one Taxonomy module package installed that the menu should display both of those in the Other package grouping rather than the Taxonomy package grouping.
Earnie
There are a lot of levels of use here that were hammered out in the initial discussions. This is a step. We as a community need to see what develops out of the initial setup. Now is not the time to leap off the bridge we just built. Just because something leverages the taxonomy system does not mean it cooperates, plays well with or bears anything but a passing relationship to any other taxonomy based module. It just means it needs taxonomy from core turned on. Is this taxonomy module a menu? A section module? A breadcrumb module? A theme module? A forum access module? Each change in how things interoperate brings us knowledge and experience. So far we have a consistent policy. Let's see what we learn from this in the 5.0 release and apply that to the 6.0 release. I suspect that we will learn that this was pretty close to what we do for 6.0 but we'll see as 5.0 will bring us a whole new realm of people, backgrounds and experiences.
Quoting Steven Peck <speck@blkmtn.org>:
What? This is set to help end user experience. One end users needs are not another's. Too many discrete groupings only serve to confuse and dilute the usefulness of the feature. In any given install there are very very few groupings of modules that will work and play well together in such a grouping.
I agree with this. I also think that unless the maintainer of a module package hasn't been given the value of the package string then the package string value should not be specified. But the documentation doesn't support this.
Dismissing the community experience and the very long discussions we've had planning this as 'merely dev type opinions' is not a correct thing to say. We have had serious participation form coders, UI folks, end users non-coders, support types, etc.
I am not "Dismissing the community experience" I am a fresh newborn Drupal convert reading your documentation and discussions for the first time. I am providing feedback so that the "community experience" can be improved. I am bringing this matter to light (again for some) because in reviewing the provided documention and submitting .info files to maintainers I did it wrong. As well, other more experienced to Drupal, have it wrong. I am trying to get the confusion resolved and the documentation modified to reflect what the value truly should be. I didn't say 'merely dev type opinions' I said 'the dev types that know what it is supposed to represent'. Reading the documentation didn't enlighten me as to what its true purpose was. Reading the documentation and looking at it functioning in the UI gave me my clues. I am both an end user and a dev type.
http://lists.drupal.org/pipermail/development/2006-November/021080.html
Yes, I have read your technical explanation before. It is the end user experience I am trying to benefit. I agree that a module in a package, package grouping, category or what ever it is needs to move to Other if there is only one in the grouping installed in the users environment. I disagree that if I have more than one Taxonomy module package installed that the menu should display both of those in the Other package grouping rather than the Taxonomy package grouping.
Earnie
There are a lot of levels of use here that were hammered out in the initial discussions. This is a step. We as a community need to see what develops out of the initial setup. Now is not the time to leap off the bridge we just built. Just because something leverages the taxonomy system does not mean it cooperates, plays well with or bears anything but a passing relationship to any other taxonomy based module. It just means it needs taxonomy from core turned on. Is this taxonomy module a menu? A section module? A breadcrumb module? A theme module? A forum access module?
<quote>If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here.</quote> Hmm... It uses Taxonomy ... Hmm... That must be the package string value I should use for my package.
Each change in how things interoperate brings us knowledge and experience. So far we have a consistent policy.
It may be an understood among those who have discussed it consistent policy but that policy hasn't been portrayed well in the documentation. Perhaps because the documentation like the policy is a work in progress and only recently has the policy been cast as consistent.
Let's see what we learn from this in the 5.0 release and apply that to the 6.0 release. I suspect that we will learn that this was pretty close to what we do for 6.0 but we'll see as 5.0 will bring us a whole new realm of people, backgrounds and experiences.
I agree. There are enough modules in CVS with info files that you can get a feel for the fact that people are confused about the package value. The affect is rather ugly. There is currently no control. My opinion for 5.x, formulated as we have had this discussion, is that if the package value doesn't fit a known list it should always be listed in Other. Earnie
I was thinking about a control scheme which might help minimize the confusion with arbitrary or wrong group strings in info files. The idea is to require acknowledgement from a group's central module in its info file. A module would declare its membership *and* the group would acknowledge it. 1. The groups would be real module names. For example, the core modules could be members of the system group. A list of member modules would be added to system.info. 2. For a module to appear in a group other than its own name, the central module of the group should aknowledge it in its info file as well. So, if a module arbitrarily declares itself as member of a group. this is ignored and the module goes to the "ungrouped" section. 3. If a module declares it own group but no other members are presently installed then this is ignored and it goes to the "ungrouped" list too. 4. If a module acknowledges other modules as members of its own group, this has no effect if the modules themselves don't declare their membership too. Membership to multiple groups is not currently possible, so I don't see any complications there. I do understand that all this may be too much, coming from a non-programmer, so comment it or ignore it as you see fit. .
@earmie: I think you could try to implement your idea on an end site by modifying the .info files. However, if you have 40 modules or so and actually try to do this categorization, I think that soon you will find yourself before dilemmas, decisions, compromises, as to how to classify this or that module. Add to that that different users will see the role of a particular module in their particular system somehow differently, and it will become more obvious why a completely unambiguous default grouping is necessary, even if it does not convey all the meaning you want.
Quoting Cog Rusty <cog.rusty@gmail.com>:
@earmie: I think you could try to implement your idea on an end site by modifying the .info files. However, if you have 40 modules or so and actually try to do this categorization, I think that soon you will find yourself before dilemmas, decisions, compromises, as to how to classify this or that module.
I have and this the reason for my post. I am trying to clarify the documentation so that others understand that the package string value should most likely not be supplied unless some concensus on this list has been given toward a package group.
Add to that that different users will see the role of a particular module in their particular system somehow differently, and it will become more obvious why a completely unambiguous default grouping is necessary, even if it does not convey all the meaning you want.
This is why a consensus is needed for the package string value. Earnie
Quoting Cog Rusty <cog.rusty@gmail.com>:
I was thinking about a control scheme which might help minimize the confusion with arbitrary or wrong group strings in info files. The idea is to require acknowledgement from a group's central module in its info file. A module would declare its membership *and* the group would acknowledge it.
1. The groups would be real module names. For example, the core modules could be members of the system group. A list of member modules would be added to system.info.
2. For a module to appear in a group other than its own name, the central module of the group should aknowledge it in its info file as well. So, if a module arbitrarily declares itself as member of a group. this is ignored and the module goes to the "ungrouped" section.
3. If a module declares it own group but no other members are presently installed then this is ignored and it goes to the "ungrouped" list too.
4. If a module acknowledges other modules as members of its own group, this has no effect if the modules themselves don't declare their membership too.
So you've just itemized a summarization of what has already be suggested with a few more ideas of implementation thrown in. New features for 5.0 are not permitted but perhaps you can help with 6.0.
Membership to multiple groups is not currently possible, so I don't see any complications there. I do understand that all this may be too much, coming from a non-programmer, so comment it or ignore it as you see fit.
I'm wondering why a "non-programmer" is posting in the development list? Earnie
On 12/21/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Cog Rusty <cog.rusty@gmail.com>:
I'm wondering why a "non-programmer" is posting in the development list?
Earnie
This question is somehow related to my suggested fix for the group info files. "Because I can and it is only a click away"?
On Thu, 21 Dec 2006, Earnie Boyd wrote:
<quote>If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here.</quote> Hmm... It uses Taxonomy ... Hmm... That must be the package string value I should use for my package.
Earnie, "package" and "module" are not the same things. Package is a module suite, in which the modules are usually architected to work closely together (like the links package, ecommerce, the erp module suite, etc). Core modules are not forming module suites with contrib modules. Contrib modules themselfs can form module suites. You won't have taxonomy module listed with other taxonomy related modules in your module list for sure. There is no taxonomy module suite (package). Gabor
Quoting Gabor Hojtsy <gabor@hojtsy.hu>:
On Thu, 21 Dec 2006, Earnie Boyd wrote:
<quote>If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here.</quote> Hmm... It uses Taxonomy ... Hmm... That must be the package string value I should use for my package.
Earnie, "package" and "module" are not the same things.
That really depends on which definition you use for package and which one you use for module. I think this definition for product from IBM as found using define:product on Google fits well: "An installable unit of a software product. Software product packages are separately installable units that can operate independently from other packages of that software product." For module I find "A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading." Since package and module both resolve to a unit of software I think of them as synonymous.
Package is a module suite, in which the modules are usually architected to work closely together (like the links package, ecommerce, the erp module suite, etc). Core modules are not forming module suites with contrib modules. Contrib modules themselfs can form module suites. You won't have taxonomy module listed with other taxonomy related modules in your module list for sure. There is no taxonomy module suite (package).
The definition for package Drupal needs to promote is one as found in the same Google search I mentioned above: "A package is a collection of modules related by authorship, maintenance, or distribution." Earnie
On 12/22/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Gabor Hojtsy <gabor@hojtsy.hu>:
On Thu, 21 Dec 2006, Earnie Boyd wrote:
<quote>If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here.</quote> Hmm... It uses Taxonomy ... Hmm... That must be the package string value I should use for my package.
Earnie, "package" and "module" are not the same things.
That really depends on which definition you use for package and which one you use for module. I think this definition for product from IBM as found using define:product on Google fits well: "An installable unit of a software product. Software product packages are separately installable units that can operate independently from other packages of that software product." For module I find "A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading." Since package and module both resolve to a unit of software I think of them as synonymous.
Earnie Names are people make them mean. If the general public uses hacker for what the tech community term cracker, and that catches on, then so be it, despite the protests of the minority (the tech community). In the Drupal universe, module has a very specific meaning. It means a file called something.module, living in the modules directory or the sites/something/ modules directory, and optionally a .install file (and as of 5.0, has its own directory, and a .info file). It is too late to rename module, since that is what it meant and that is what it will continue to mean. Module has other meanings in other parts of the industry, but that is irrelevant to us in the Drupal world.
Package is a module suite, in which the modules are usually
architected to work closely together (like the links package, ecommerce, the erp module suite, etc). Core modules are not forming module suites with contrib modules. Contrib modules themselfs can form module suites. You won't have taxonomy module listed with other taxonomy related modules in your module list for sure. There is no taxonomy module suite (package).
The definition for package Drupal needs to promote is one as found in the same Google search I mentioned above: "A package is a collection of modules related by authorship, maintenance, or distribution."
Personally, I never liked the name "install profile" because it somewhat clashes with the "profile module" that has specific fields for the users. It will confuse users. I prefer to term them "packages", but I think Adrian is working on a broader definition of package a la Debian way. (Hey Adrian, jump in and correct me if I am wrong here). If the name "package" is not reserved for some future thingie, then I am all for renaming install profiles, although it may be too late to do so.
participants (5)
-
Cog Rusty -
Earnie Boyd -
Gabor Hojtsy -
Khalid B -
Steven Peck