After updating to Features 7.x-2.0-alpha2, I am finding that some dependencies are not appearing in one of my features, and recreating the feature causes these dependencies to be dropped. Here is the contents of my feature's .info file:

name = Base
description = Sets up base configurations.
core = 7.x
package = Features
php = 5.2.4
dependencies[] = cas
dependencies[] = cas_attributes
dependencies[] = cas_ldap
dependencies[] = ctools
dependencies[] = fe_block
dependencies[] = features
dependencies[] = ldap_servers
dependencies[] = libraries
dependencies[] = strongarm
dependencies[] = token
features[ctools][] = ldap_servers:ldap_servers:1
features[ctools][] = strongarm:strongarm:1
features[features_api][] = api:1
features[field][] = user-user-field_address
features[field][] = user-user-field_firstname
features[field][] = user-user-field_lastname
features[field][] = user-user-field_phone
features[field][] = user-user-field_title
features[ldap_servers][] = work
features[variable][] = cas_attributes
features[variable][] = cas_login_drupal_invite
features[variable][] = cas_login_form

After either using the 'Generate feature' option or 'Download feature' options, a diff looks like this:

Vincents-iMac:d7 vincentmassaro$ git diff sites/all/modules/features/base
diff --git a/sites/all/modules/features/base/base.info b/sites/all/modules/features/base/base.info
index 510f22c..27d1d5c 100644
--- a/sites/all/modules/features/base/base.info
+++ b/sites/all/modules/features/base/base.info
@@ -3,16 +3,11 @@ description = Sets up base configurations.
core = 7.x
package = Features
php = 5.2.4
-dependencies[] = cas
-dependencies[] = cas_attributes
-dependencies[] = cas_ldap
dependencies[] = ctools
-dependencies[] = fe_block
dependencies[] = features
dependencies[] = ldap_servers
-dependencies[] = libraries
dependencies[] = strongarm
-dependencies[] = token
+dependencies[] = text
features[ctools][] = ldap_servers:ldap_servers:1
features[ctools][] = strongarm:strongarm:1
features[features_api][] = api:1

The Recreate features page does NOT show the cas, cas_attributes, cas_ldap, fe_block, libraries, or token modules as dependencies. Using drush fu base does not cause any changes to be exported. Thanks in advance.

Comments

This behavior does not happen with 7.x-1.0 but occurs in 7.x-1.1-alpha1. Appears to have been introduced in http://drupalcode.org/project/features.git/commit/a48b0a47af58f0afd32984....

Confirmed. Manually added dependencies are not saved in the feature in the new UI. Definitely a serious issue that I'll work on a solution for soon.

Great, thanks. Can I safely downgrade back to 7.x-1.x with my Features that have been updated to 7.x-2.x? The only main changes I saw were that roles permissions arrays were defined with a named key instead of a number.

Status:Active» Fixed

Fixed in commit 36714e8.

And yes, the actual export files are compatible between 7.x-1.x and 7.x-2.x. The permission fix works for 1.x also. If you re-export the feature with 1.x then your user permissions will go back to using a number instead of string key.

Awesome, thanks for fixing this so fast! Didn't even have a chance to downgrade ;)

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

Reopening this case because the fix did not cover the drush command features-export.

I looked at features.drush.inc and noticed some of the same functions are being used as in _features_export_build().
Is it safe to assume that the fix should still be ported to the Drush command?

I would normally write my own patch for this, but the underbelly of Features is a bit too obscure for me.
I did notice that the Drush commands are all pretty verbose, couldn't you "just" make them wrappers of the functions behind the UI?

For easy reference, see commit 36714e8.

Version:7.x-2.0-alpha2» 7.x-2.0-beta1

Tested and confirmed to be broken in beta1 by the way.

Version:7.x-2.0-beta1» 7.x-2.x-dev

I got as far as tracing the dependencies back to features_get_info(), where I added the following debug just before returning:
print_r($cache->data['feature'][$name]->info['dependencies']);

But then I saw that the list of dependencies was infact now correct, which makes me wonder if it could be a caching issue (i.e. regenerating the feature using a cached version of the dependencies).

Setting version to 7.x-2.x-dev as that what a patch would be developed against. I'm running 7.x-2.x-rc2.