Add a relation between module names and project names

Normally if you add dependencies to fe_block or fe_nodequeue this should work. There is indeed no features_extra module but having this empty module would probably confuse people that enable it and find that nothing happens.

I just tried it with Drush 5.8 and it works fine. I just created a test module which depends on fe_block:

$ drush en test_module -y
The following extensions will be enabled: test_module, features, fe_block
Do you really want to continue? (y/n): y
fe_block was enabled successfully.                                                             [ok]
test_module was enabled successfully.                                                          [ok]
features was enabled successfully.                                                             [ok]

Ah yeah I understand now. You want to use the feature of Drush that automatically downloads needed dependencies when enabling a module. This is something that should be handled in the Project Dependency module. I don't know if this relation between the name of a (sub)module and the name of a project on drupal.org actually exists. Probably there already is an issue about this, since Features Extra is not the only project that has module names that differ from the project name, but I could not find anything.

I'm going to move this to the Project Dependency queue, maybe we can get some input there. I wil update the first post too.

The problem with this is that we need to access a data store to retrieve these mappings. This could be something like a cached XML file hosted on drupal.org which is updated once every 24 hours. But maybe this is not even necessary, we could also solve this by adding a directive such as the following to the module info files:

project_dependencies[] = features_extra

This could be used by Drush and the test bots to add to the list of projects to download in the case of non-matching module names.

Added more general information about the issue, this is being moved between queues.

If this feature were generally available (esp. via a web service on drupal.org), Drush would use it. Thanks for your efforts on this module.

Project Dependency has database tables that store this information. Accessing the data has not been straightforward but in #2047557: Support Drupal 8-style *.info.yml files I added a function in the patch for comment #81 that has a function project_dependency_guess_project($parsed_dependency, $api_tid) that returns a project that contains the module. As the name implies, more than one project can contain a module with the same name so the result is not unique. The patch supports the addition of an optional project name to dependencies in the .info or .info.yml files. If the project name is not found then this function is called and the project name is added to the dependency stored by Project Dependency.

$parsed_dependency is the structure returned by the core function that parses the .info or .info.yml files. $api_tid is the term ID for the Drupal version (7.x or 8.x). I can add a wrapper function that uses the Drupal version rather than the term ID. I am not sure the best way to expose this information on drupal.org but I do not think it would take a lot of additional coding.