On Saturday 25 November 2006 5:35 am, Konstantin Käfer wrote:

Am 25.11.2006 um 13:47 schrieb Morbus Iff:

...

...

I have been looking, and probably missed something crucial, but I fail to find a list of standardised package = classifications.

Bèr probably meant that there are no guidelines on how to use the package field. Module authors can invent arbitrary new names and use them. That way, you'll end up with 10 categories with 1-2 modules each.

Why not ask module owners to make the default be the category that they list it under at drupal.org. Then those generic categories could be the guideline for what to put in the 'package =' line. --Vernon

...

Naming-wise, the package should almost /always/ be the name of your distribution - CCK and Ecommerce are made up of a ton of different modules but are all colloquially referred to as "CCK" or "Ecommerce", and that's what their CVS name and module URL are. Thus, that is their package names as well.

That's true. But we need to document it somewhere. It won't work with a tacit agreement.

Konstantin Käfer – http://kkaefer.com/

Op zaterdag 25 november 2006 14:35, schreef Konstantin Käfer:

...

...

I have been looking, and probably missed something crucial, but I   fail to find a list of standardised package = classifications.

Bèr probably meant that there are no guidelines on how to use the   package field. Module authors can invent arbitrary new names and use   them. That way, you'll end up with 10 categories with 1-2 modules each.

Let me be more specific. I have Quicktags. Its a module that lives in the area of tinyMCE, fsckeditor and so forth. Basically I assumed that such module would have to be grouped in the same sort of category. Though It seems I am kibdof wrong.

...

Naming-wise, the package should almost /always/ be the name of your   distribution - CCK and Ecommerce are made up of a ton of different   modules but are all colloquially referred to as "CCK" or   "Ecommerce", and that's what their CVS name and module URL are.   Thus, that is their package names as well.

That's true. But we need to document it somewhere. It won't work with   a tacit agreement.

It is becoming clearer to me now. IS it correct to summarise this, for module devs, as: Package is left emtpty, unless your module consistst of many modules -- a package. ? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: sympal.nl

Modules that extend a particular "parent" module, such as CCK, Views, Organic Groups, etc. use the "parent" module's name as the package. I think you'd use this when your module would basically be completely useless on its own without said parent module.

I think this should be the /only/ standard. If we meant "package" as "category", then we would have named it "category". There are three different names being bandied about here. I will define them: * package: *closely* related modules -- probably require each other. * distribution: a single tarball generated from the d.o release system. * category: the general type of module or feature it provides. In the realm of .info files, currently we only care about package and distribution. I have /no problem what so ever/ with defining "category" to match d.o entries. But "package" should not be used for this.

Modules that are not useless on their own tend to be classified by their function, such as Voting, Development, etc. There doesn't appear to be any standardization here, but it probably makes sense for the Drupal.org category name and package name to match.

The problem with using category as a sorting function on admin/modules: * People generally can't categorize correctly. * "category" in an .info file is a lot slower to change than the category list on d.o - we'll get out of date within, oh, a month. * modules can be more than one category on d.o, and thus, so should the .info files allow. but if we based admin/modules on category (or even if we abused "package" in this way), then a module with three categories would be categorized under what? the first entry in the .info file? this would become a huuUge mess. people don't categorize in the same way as everyone else - this is why free tagging is so great. I support a patch to rename "Uncategorized" to "Other". I support any of my emails being munged into a documentation page.

I've done a grep of contrib-head: http://drupal.pastecode.com/8783

Of this list, I'd only keep: Audio Bot (disclouse: this is mine) CCK Chat (maybe: would need to investigate more) E-Commerce Event Feed Parser Organic Groups Station Video Views Voting (but ONLY if it uses/requires eaton's VotingAPI) And taxonomy_list needs to be corrected immediately - it abuses itself into "Core - optional", which it most certainly isn't. -- Morbus Iff ( you shouldn't have come here ) 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

Angela Byron wrote:

...

Is there a list somewhere that I can make more visible? Or do i need to start one, and in that case, are there some (de-facto) standards that I missed?

I think making one would be a good idea.

I've done a grep of contrib-head: http://drupal.pastecode.com/8783

Here are the de-facto standards:

- Modules that extend a particular "parent" module, such as CCK, Views, Organic Groups, etc. use the "parent" module's name as the package. I think you'd use this when your module would basically be completely useless on its own without said parent module.

- Modules that are not useless on their own tend to be classified by their function, such as Voting, Development, etc. There doesn't appear to be any standardization here, but it probably makes sense for the Drupal.org category name and package name to match.

Here is the standard I wrote for the update modules 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 'Uncategorized'. 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 there are developers who put just their module's name as the package, then we definitely need to do something and try to correct this behavior, as that's not really how things should work for most modules. And if we want to create a list of standard groupings, that's perfectly fine too, but it needs to be easy to find. Let's create a page on this in the Module Developer's section and get this information into it.