integrate with the features module

You forgot the patch :)

Cool, I see some of the code from the 'export to module' issue is used :)

> As alternative we could also rely on the rule categories and only allow to export by category - as rules + rule sets implementing a feature should be ideally in the same category nevertheless.

I think that's a good practice but I don't think we should force users to do it. Ideally we should have 3 sections like in the current rules export for rules/ rules-sets/category

btw, I have noticed that the rules name aren't renamed.

> Add dependencies on required modules

#524834: Add module dependency information to item

Hi.

I'm triying to modify this patch but I have a problem with the cvs versions.

This is what i'm doing.

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d rules -r DRUPAL-6--1 contributions/modules/rules/

modifications....

cvs diff -up > ~/Desktop/rules_features_3.patch

But i'm getting more diferences that I made. For example:

-// $Id: rules.export.inc,v 1.1.2.1 2009/07/15 16:00:00 fago Exp $
+// $Id$
 
 /**
  * @file Provides export functionality and integrates with the features module.
  */
 
 /**
- * Export all items given to code, where $export has to be an array of arrays
+ * Export all items given, where $export has to be an array of arrays

I didn't change these lines ¬¬

What I'm doing wrong?

Ok, I discovered the problem. part of #350881: Make exporting to module easier was commited and for this reason the patch is a bit diferent.

Well, this patch add a way to get the module dependencies for rules.

Maybe there is a better way to do this, but this works.

It seems that there isn't a way to get the module for the "event" for the rules, but actions and conditions are covered.

Just a quick heads up that in features HEAD hook_features_api() has been refactored -- the new format is cleaner and easier to understand. It should return an array of keyed component information, so that each component can define its own options separately:

function rules_features_api() {
  return array(
    'rules' => array(
      'feature_source' => TRUE,
      'default_hook' => 'rules_defaults',
      'file' => drupal_get_path('module', 'rules') .'/rules.export.inc',
    ),
    'rules_sets' => array(
      ...
    ),
  );
}

We'll try to get a stable-ish tag of features HEAD out soon.

New patch:
* added module dependency retrieval
* switched to new features_api()

TODO:
* rename rules to avoid collisions
* Implement revert

Another patch:
* added revert()
* removed rules within rule sets from the rules export selection

I removed renaming of rules for now, because I haven't found a satisfying solution yet. rules_features_export() may be called twice, so prefixing rule names there is also done twice. But we need to prefix them there, because that information is written to the .info file. Then we also need to rename the rules during the actual export, where the $data parameter comes in renamed already and must be named back to the original name to find the rule. Afterwards the rule names must be renamed again.

All in all very ugly .... ideas welcome, maybe I missed something.

I have made some testing for this patch:

It seems to work fine, however there is a interesting thing to fix.

If diff module is installed, features allows users to see the differences between an unchanged rule and a overwritten rule.

For this example I only have changed the value of the condition "User has role" to 'Negated' and diff shows a lot of changes.

Well, in fact the only change that matters is

-	'#negate' => 0,	+	'#negate' => 1,

But instead of that I'm getting something else (the code attached in this issue).

Maybe the solution for this is include all the values for a rule when it is exported, for example, even if users didn't check in an options, export it with its default value

What do you think?

@fago: The removed lines are added again at the bottom of the file. I think that rules is rebuilding the export in a different way.

Just a remark #419644: Use CTools to export . Features module already supports CTools export, so maybe our effort should be towards integration with CTools? (for Rules 2 of course).

@fago: Posted a hook request in the features issue queue: #551490: Allow renaming of components

subscribe...

Desperately waiting for the features integration feature!

Very cool! we'll check it out soon :)

Awesome! I'm a very excited beta tester :)

I'll try it out next week.