Remove dependency on Features from generated features

AFAIK Featuers is added only when Features is the implementing module (in cases such as user permissions). If you will export Just Views/ Rules, I don't think it includes Features.

The short here is that Features doesn't add itself as a dependency unless it is providing the export/rebuild integration itself for components that otherwise would not be exportable (e.g. user permissions).

There is one exception to this, namely the node type component. This is because we cannot export into hook_node_info() using the 'node' key (which gets special treatment). Instead we use Features with wrappers around the default hook_access(), hook_form(), etc.

Why don't we write hook_access(), hook_form(), etc. with default behaviors to the new feature module? This is basically a design decision -- features handles exportables, but hook_access() and hook_form() are not exported settings. They act a lot more like handlers, or pluggable behaviors in the node system. So they can not really be programmatically written & updated like other features components.

For functions like hook_access, would it be too farfetched to ask for the features_access function to allow some extendability? For example, it is impossible to take control of hook_access for a module exported with features.

For now, I'll create a new module to do what I need to do.

James

If you change the module in hook_node_info, newer versions of features should preserve the module key, then you can use node hooks (but remember to implement the required hooks; guide I wrote on it a while ago on doing it, just updated to reflect that features does keep the module key, http://drupal.foxinbox.org/drupal/guides/custom-access-checks-hookaccess...).

#3: Something like this?

/**
 * Implemenation of hook_access()
 */
function features_access($op, $node, $account) {
  $map = features_get_component_map('node');
  $func = $map[$node->type] . '_' . access;
  if (function_exists($func)) {
    return $func($op, $node, $account);
  }
  return node_content_access($op, $node, $account);
}

EDIT: Went over this again, hefox makes sense. It's counter-intuitive that Features won't update over the module element, but if that's the case there's no reason for this overhead.

Closing this for lack of activity. Pure-Features (like Views, ctools exportable) already do not require Features module. "faux" exportables such as Fields require the routines in the Features module to support the hooks for making the features work, so there is no way to remove that dependency.