Confused: package value of info files
I have submitted a few info files for inclusion in the module and have at times pointed to node/101009 by the maintainers to say that package shouldn't be given. However, node/64279 doesn't state that but instead suggest "Your arbitrary grouping string" as the value. http://drupal.org/node/64279 http://drupal.org/node/101009 Can we have a consensus for what value should be given for 5.0 to package and can we update both nodes with the consensus? I think that the original idea was for package to be used by those module packages that contain more than one module to group their package together. However the design of the 5.0 menu treats package more as a category or package type. Should there be a defined list of what the value of package should be? There is a list in suggested values in the two nodes listed above but one important one is Taxonomy and it isn't listed. There are several modules that could be grouped under Taxonomy and I think that would be a good thing. If someone, as I have, decides to install every module in their test system to evaluate the validity of each module it quickly becomes a matter of importance for the ``Other'' package to be reduced. The Other category is currently long list. Earnie Boyd
Earnie Boyd wrote:
I have submitted a few info files for inclusion in the module and have at times pointed to node/101009 by the maintainers to say that package shouldn't be given. However, node/64279 doesn't state that but instead suggest "Your arbitrary grouping string" as the value.
From the above page: If you assign a package string for your module, on the admin/build/modules page it will be listed with other modules with the same category. If you do not assign one, it will simply be listed as 'Other'. Not assigning a package for your module is perfectly ok; in general packages are best used for modules that are distributed together or are meant to be used together. If you have any doubt, leave this field blank.
http://drupal.org/node/101009 From the above page:
If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here. If left blank, the module will be listed as 'Other'. In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not. If used, the package string is used to group modules together on the module administration display; the string should therefore be the heading you would like your modules to appear under, and it needs to be consistent (in spelling and capitalization) in all .info files in which it appears. It should not use punctuation and it should follow the Drupal 5 capitalization standard as noted above.
I think that the original idea was for package to be used by those module packages that contain more than one module to group their package together.
This is correct.
Can we have a consensus for what value should be given for 5.0 to package and can we update both nodes with the consensus?
We have consensus already. Please do not muddy the waters further.
Quoting Earl Miles <merlin@logrus.com>:
We have consensus already. Please do not muddy the waters further.
I am not trying to muddy the water I am trying to clear the mud from the water before we have to drink it. Check the info files already existing and you'll come to see what I mean. A couple I have submitted patches for to remove them from "Core - Optional". Besides, shouldn't we give the user a nice grouping for modules that are similar. The sentence "If you assign a package string for your module, on the admin/build/modules page it will be listed with other modules with the same category." seems to indicate that this is desired. It will give the user a better 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? Earnie
Earnie Boyd wrote:
I am not trying to muddy the water I am trying to clear the mud from the water before we have to drink it. Check the info files already existing and you'll come to see what I mean. A couple I have submitted patches for to remove them from "Core - Optional". Besides, shouldn't we give the user a nice grouping for modules that are similar. The sentence "If you assign a package string for your module, on the admin/build/modules page it will be listed with other modules with the same category." seems to indicate that this is desired. It will give the user a better 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, overuse of this field results in a page where, for most users, you have 12 contrib modules enabled, each of them in their own category. This is of no value whatsoever. Your use case (installing every module out there) is a rare case and, well, tough. Making the normal case tougher to make your case easier is not useful.
Quoting Earl Miles <merlin@logrus.com>:
Earnie Boyd wrote:
I am not trying to muddy the water I am trying to clear the mud from the water before we have to drink it. Check the info files already existing and you'll come to see what I mean. A couple I have submitted patches for to remove them from "Core - Optional". Besides, shouldn't we give the user a nice grouping for modules that are similar. The sentence "If you assign a package string for your module, on the admin/build/modules page it will be listed with other modules with the same category." seems to indicate that this is desired. It will give the user a better 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, overuse of this field results in a page where, for most users, you have 12 contrib modules enabled, each of them in their own category. This is of no value whatsoever. Your use case (installing every module out there) is a rare case and, well, tough. Making the normal case tougher to make your case easier is not useful.
I will agree with this, to some extent. But others have already populated the package value incorrectly. I do not think that it should be left to "Whatever value I choose" and that the http://drupal.org/node/64279 reference should more strongly suggest that a value not be given. I still think though that if I have more than one Taxonomy module installed that it should give me a Taxonomy grouping in the menu. So we could smarten the menu display so that if we have only one module in a package group the system will move the package value to Other and if I install more than one it leaves it in the package grouping. This enhancement would eliminate the one package per grouping case that actually currently exists and is really ugly. Earnie
On Dec 20, 2006, at 8:03 PM, Earnie Boyd wrote:
But others have already populated the package value incorrectly.
this is a good argument for submitting issues and patches that fix the incorrectly classified .info files, not for changing core to try to defend ourselves from poorly classified modules. contrib is a vast, dangerous place, full of varying levels of quality and sanity of the code. the code for drupal core would have to be at least 10 times larger, more complicated, and slower, if it had to try to protect itself from every stupid thing some contrib author decided to do. ;) there's no shame in "other", and there's no shame in having lots of modules in there. remember, 4.7.x just has everything, core/contrib/ CCK/OG/other/whatever all in 1 giant, alphabetical list. so, even just "Core-Optional" vs. "Core-Required" vs. "Other" is a vast usability improvement right there. for extra-credit, all the CCK fields can be in another group, etc, etc, but we should aim for 3-7 groups total, not 15-20. i don't think we need a feature to automatically re-classify single-group modules back into other... no one should be distributing modules in their own group in the first place. if they do, it's their problem, not core's. cheers, -derek
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: http://lists.drupal.org/pipermail/development/2006-November/021080.html -- Morbus Iff ( whooooooo's hoooouuuuuse? ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
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.
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
Earnie Boyd wrote:
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. Taxonomy, in particular, is such a general purpose area that it's not at all clear that it makes a useful grouping. Does Taxonomy Access Control belong with Taxonomy or with Access Control? Does Taxonomy Block belong with Taxonomy or with Blocks (or web design)? Does Taxonomy Menu belong with other menu modules?
I agree that the underlying policy and grouping needs work, but I don't think the answer is to allow packages around implementation tactics. Perhaps it should be enhanced so that a module can appear in more than one group. Or perhaps users should be allowed to reorganize things themselves. But at this point in time, I don't think there's enough experience with the new organization, and it would be premature to change the current policy. Gary
Quoting Gary Feldman <dpal_gaf_devel@marsdome.com>:
I agree that the underlying policy and grouping needs work, but I don't think the answer is to allow packages around implementation tactics. Perhaps it should be enhanced so that a module can appear in more than one group. Or perhaps users should be allowed to reorganize things themselves. But at this point in time, I don't think there's enough experience with the new organization, and it would be premature to change the current policy.
I am fine with this statement for 5.x if and only if http://drupal.org/node/64279 and http://drupal.org/node/101009 make a stronger case to leave package empty or unspecified unless the module maintainer has been given permission otherwise. Currently this policy isn't clear. <quote>package = "Your arbitrary grouping string"</quote> is the policy based on the documentation because it is the example given and most coders are nothing more than a group of people playing follow the leader because they don't have time to stop a reflect on life's puzzling mysteries. My guess is few have clicked the link reference on 64279 to 101009 to read the more information on .info files. My guess is that few have understand the "If you have doubt, leave this field blank." I would like to see "Your arbitrary grouping string" changed to "Your assigned grouping string" and I would like the paragraph beginning "If you assign a package string ..." to read as follows and I would remove all of the suggested examples: If you have been assigned a package string for your module it will be listed with other modules containing the same string value on the admin/build/modules page. If you have not been assigned a package string for your module then this value must remain unspecified it will be listed in the Other grouping on the admin/build/modules page. Earnie
Earnie Boyd wrote:
I would like to see "Your arbitrary grouping string" changed to "Your assigned grouping string" and I would like the paragraph beginning "If you assign a package string ..." to read as follows and I would remove all of the suggested examples:
If you have been assigned a package string for your module it will be listed with other modules containing the same string value on the admin/build/modules page. If you have not been assigned a package string for your module then this value must remain unspecified it will be listed in the Other grouping on the admin/build/modules page. How about something even stronger, at least for the short term:
package = "Your package name, if any" A package is a group of modules designed to work together. Two big examples are E-commerce and Organic Groups. If you use this, the maintainers of the group must agree to use the same string. They should agree to document all dependencies and incompatibilities within the group. The overwhelming majority of modules will not use this field. Gary
Quoting Gary Feldman <dpal_gaf_devel@marsdome.com>:
Earnie Boyd wrote:
I would like to see "Your arbitrary grouping string" changed to "Your assigned grouping string" and I would like the paragraph beginning "If you assign a package string ..." to read as follows and I would remove all of the suggested examples:
If you have been assigned a package string for your module it will be listed with other modules containing the same string value on the admin/build/modules page. If you have not been assigned a package string for your module then this value must remain unspecified it will be listed in the Other grouping on the admin/build/modules page. How about something even stronger, at least for the short term:
package = "Your package name, if any"
This is still too open ended. If you change it to package = "Your assigned package name, if any" then it becomes more understood that some consensus must be made before a string value is to be assigned.
A package is a group of modules designed to work together. Two big examples are E-commerce and Organic Groups. If you use this, the maintainers of the group must agree to use the same string. They should agree to document all dependencies and incompatibilities within the group. The overwhelming majority of modules will not use this field.
I like this and enforces the idea that it the value should most likely not be supplied and that consensus is necessary before assigning a value. Earnie
On 21 Dec 2006, at 15:49, Gary Feldman wrote:
If you have been assigned a package string for your module it will be listed with other modules containing the same string value on the admin/build/modules page. If you have not been assigned a package string for your module then this value must remain unspecified it will be listed in the Other grouping on the admin/ build/modules page.
How about something even stronger, at least for the short term:
package = "Your package name, if any"
A package is a group of modules designed to work together. Two big examples are E-commerce and Organic Groups. If you use this, the maintainers of the group must agree to use the same string. They should agree to document all dependencies and incompatibilities within the group. The overwhelming majority of modules will not use this field.
(I agree with Earnie's points and was also the reason why I didn't wanted to commit the package patch in first place. Peer pressure driven by release candidate frenzy/frustration, make me commit it anyway.) This kind of documentation is a bit of a "hack". I'm a firm believer of 'fixing the root of the confusion', rather than 'documenting the confusion'. Most people, including myself, don't care to read the small print before setting a silly field. We just copy-paste the field from another .info file and follow our intuition. We're cowboys like that. ;-) So the question becomes: can we make this more intuitive? Can we improve the default behavior? Can we make this work for copy-pasters like me? Can we optimize the UI to deal with a multitude of package names? (Make the package names less prominent, but still sort modules by package name.) Can we ignore unique package names in the UI? (Only group modules by package if there are more than two modules in a given package.) If we can fix this in the code, I'd prefer to fix it in the code regardless of the RC status. If we can't fix it in the code, we need a policy. Personally, I'm not a fan of rules (especially not of rules that state you need agreement first) because slowly but certainly, they turn things into a bureaucracy. So, I'm OK with the proposed documentation but I'd remove the "you need agreement" clause. Oh, and if someone comes up with a good patch, chances are I'll commit that. -- Dries Buytaert :: http://www.buytaert.net/
participants (6)
-
Derek Wright -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Gary Feldman -
Morbus Iff