Distinguish between features and non-feature modules

Concretely, what do you have in mind here?

It's not clear to me what you are advocating in terms of actual actions here... do you mean that

1. features should be treated as a separate package type in Drupal core, e.g. there is a features/ directory in addition to modules/ and themes/ directories
2. there should be a separate project type on Drupal.org for features so that people can contribute features to d.o without confusing users
3. features should actually stop being modules in the technical sense, i.e. their hooks should not be called by Drupal

#1 I am mixed on. There are already Features hosted on D.O. (Such as the debut features) muddying the waters. But if #1, what do you do about features packaged as sub-modules? I've taken to creating a features/ directory in some of my projects to contain Features that provide an out-of-the-box base application built on top of a module. And while a logical distinction on the filesystem is nice, Features are ultimately just another module. It's kind of site or distribution specific to gather them up into their own directory.

To me, the bigger distinction is contrib/ and what I've started thinking of as extra/, which is where all non-D.O hosted projects that are not site-custom should go.

#2 makes sense to me. Or possibly a secondary module taxonomy. D.O's module vocabulary is really garbled between what a module does and what it relates to. I'd like to see those separated, so you can have API modules, Application modules, UX Enhancement modules, etc more easily searched for, separate from "This is a CCK/Nodereference/OG/etc" module.

#3 is a bad plan that limits the versatility of Features. We don't need to double the entries for Features modules in the systems table just for hook_form_alter().

As someone that uses features as modules (as in, I use feature exports, manual feature supplied hooks like hook_content_default_fields along, and other non-features hooks... in the same module sometimes), I'm pretty much against 1 and 3.

I like grayside's later option for two though; I want free tagging for modules (actually, I want uh... community driven tagging? for modules. Like hulu).

1) Adding package would have to be optional (what is the default at the moment?). There's some discussion here #894572: Features with only module dependencies not recognized as features on adding something to .info to distinguish them as a feature.

2) The taxonomy already has been added, see #760878: Add a "Features" term to the taxonomy vocab for modules on d.o or http://drupal.org/taxonomy/term/11478; what I like is grayside idea of more broad/clear categorization so modules are easier to find in general, but that is not a features specific thing.

If we separate the two domains, modules become focused on framework improvements to Drupal and features will be focus on ease of implementation.

Not all modules that might ship with features are epic API modules. I think if a contrib version of the Book module existed, it should ship with a feature defining a default/example Book content type. I think this is a best practice discussion, rather than something which should be mandated by infrastructure.

Add package = Features to .info file to group them in module configuration page.

As @hefox said, this should not be mandated. The most important (IMO) categorization of a Features module is its relevance to the site, not the fact that it is a special class of module. (Random thought on package naming: D.O taxonomy used to provide the D.O packaging script with a fallback package name, instead of filing everything under "Other")

[Features taxonomy term]

It's nice to see the taxonomy term. I noticed it before--based on initial usage, I thought it was for Features-integration modules. Now I see it is for the whole ball of Features-related wax, which takes us back to minimally useful terminology. Features-related modules and "Applications (such as Features-based)" are not the same thing in a site-building life-cycle.

EDIT: Removed redundant paragraph.

subscribe

I think an entire Project Infrastructure for a "Getting Started" feature can be excessive. The answer to Modules page clutter is to think about the Modules page itself.

#13: That's why I'm suggesting the way Taxonomies are used with modules on D.O should be rethought. In the mean-time, there probably is a need for a separate "Features integration" term.

I'm not sure why I was directed here, but...

I'm caring about both the technical and the end user side. I do not want to become a project where there are 11 different names for "Extend your website's functionality". I don't want "Modules" and "Features" and "Components" and "Mambots" :P and...

To an end user, extra jargon is just a barrier. If we call all of these things "Modules," which they are, they instantly know, "Oh. That's one of those things I download and stick in my sites/all/modules directory and turn on with a checkbox and then configure somewhere in the admin panel."

Making a distinction between a module that provides an API like Voting API and a module that provides "building block" functionality like Views and a module that provides a "one-click photo gallery" like some Features-generated module can easily be handled in the Project's description. There is absolutely no reason to burden an end user with having to know that kind of distinction. They only need to know what it does, what its list of dependencies is, and how to go about configuring it.

Calling out the "one-click configuration" type of modules can easily be handled with a tag, which is what #760878: Add a "Features" term to the taxonomy vocab for modules on d.o is about.

This is an infrastructure question, not really related to D7, but I think we should make the distinction. For me a feature is a bunch of exportables in a package, yes you can add actual actual custom code into a feature and yes you can add exportables to modules, but IMHO that is the grey area in between that clouds the bigger picture.

1) It would make it ok to contribute export-only-features, because most people think features are too simple to contribute as modules, even though they could be valuable at least as learning material.

2) It is too easy to make features to treat them as modules: we now have 6000 modules, if features really take off as contributions (which is a good thing) we would go to 10-20k in no time. Imagine having to sift through all that to find the actual modules (projects that contribute API's)...

Imagine having the top 10 content types on the CCK project page...

Just to be clear, features can be added to d.o; see the before mentioned issue queue post on the taxonomy term.

1) It is ok to contribute feature-only modules. I have absolutely no idea where this FUD comes from. Feature modules are just regular modules, with a tag to denote them as a "Features package."
2) Why shouldn't there be 20,000 feature modules, if they're actually useful to the community? If there are feature modules that are super similar, we will use the normal community processes to encourage module maintainers to work together. The really useful "API-like" modules will always be on the first couple pages of http://drupal.org/project/modules because the 20,000 feature modules depend on them.

For me a feature is a bunch of exportables in a package

Yes, for you, with a 5-digit user ID, permanent member of the Drupal Association, who's been to 4 Drupalcons, who's been using Drupal since 4.something, I'm sure that's what a feature is. :) I'm similarly sure that to anyone who's seen Development Seed speak about features, or for people who are relatively clued into the Drupal community, that's what features are.

However, for the other 99.9999% of people who want to extend their Drupal site, they're just modules. Calling them something other than modules just adds confusion.

If Drupal core ever makes a distinction between modules and features, then it would make sense to do so in contrib. But it doesn't, and won't until at least Drupal 8.

@philbar That's a Developer's perspective not a Site-Builder's perspective. I bet you Site Builders see Feature stuff as modules, and weird API modules as annoying library requirements that happen to be called modules also.

There are countless modules that are a blend of both, and it is too soon to see how module practices shift on a universal level. Does everything with a Content Type cooked in count as a Feature?

EDIT: Snipped to avoid redundancy around D.O taxonomies and such.

This is what the discussion is all about. I'm not looking for an instant fix, but rather a long term vision for Features.

Ok, then my stance is still no. A site builder doesn't give a crap what files are or are not in the module directory, what dependencies it has or doesn't have, whether the .module file contains hook implementations or ASCII art of pirates swashbuckling, or anything about how that module was created including whether or not the developer was playing Wu-Tang Clan in the background while building it. All of these details are completely, utterly irrelevant.

What they care about is what the module does for them, and whether it achieves their goals. And this can be derived from a combination of the project name + description + category + screenshots + documentation.

I would even argue that a developer doesn't care about these under-the-hood details, either. They're looking for code that is performant, well-documented, organized, etc. This is true regardless of how the module was created, and how many lines of code it has in its .module file.

Also, speaking as a developer, I have never once succeeded in creating Feature that is truly only configuration. The exportable support in contrib is simply not there yet, and there is almost always some elbow grease in terms of UX smoothing out as well which ends up manifesting itself as hook_form_alter()s and whatnot. I therefore fail to see what makes my "Feature" module different than modules I built 3 years ago that contained Views exports and whatnot. Creating such a false distinction is simply lying to people, especially since there are a lot of "one-click configuration" style modules that aren't based on Features at all.

So who, really, is this distinction trying to help? How does it do more good than harm?

It sounds like what you're actually after is making it easier for site builders to find modules that fit their needs. I absolutely agree with that goal. So let's improve the search tools on Drupal.org. Introducing vocabulary/concept complexity isn't the way to do it, IMO.

@Angie: I guess my immediate objective would be to have a list of features that implement a certain module. But that could simply be a little list in the bottom of a project page with 10 most important projects that have this module as a dependency with a more link to see the gazillion of other modules (be it features or not features) that do so.

@philbar: Using features to codify advanced settings in a simple UI might work, but it's not going to be easy to get sufficient features to make this work, and have cohesive feature sets that all work together.

Closing this for lack of activity. I believe this is now handled by the latest dev version. Please re-open this issue if you can reproduce it in the latest version.