Motivation / use case
I maintain the module package https://drupal.org/project/cfr, which currently requires composer_manager to be installed, and where composer_manager is required in the *.info files of some of the submodules.
Now I also want to support sites that install all their modules via composer, e.g. using https://github.com/drupal-composer/drupal-project.
However, the auto-generated composer.json files now require composer_manager, because they are generated from the *.info files.
composer_manager is undesirable in this context and even creates a conflict with composer_autoloader which is required by drupal-composer/drupal-project.
One specialty here is that there is no actual module named 'cfr', all the modules in the package are submodules like 'cfrapi', 'cfrplugin', 'cfrplugindiscovery' etc. This may or may not be a good choice, but it is how it is now.
Technical observations
I found, by looking into ~/.composer/cache/repo/https---packages.drupal.org-7/*, that Composer / packages.drupal.org creates "meta packages" for submodules.
Even if the submodule already has a composer.json file, this is replaced with a generated composer.json file that requires only the module dependencies from the *.info file, not the 3rd party dependencies from the composer.json file.
This means: - The meta packages do require modules like drupal/xautoload and drupal/composer_manager. - The meta packages do NOT require vendor libraries like donquixote/annotation-parser anymore. - The main package 'cfr' seems like a combination of the meta-packages, but still does not require the vendor libraries.
Question
What do I need to do in a contrib module to support both composer_manager AND the full-composer scenario?
How can I avoid the 'composer_manager' dependency in the generated composer.json for metapackages for the submodules?
Especially, with the scenario above?
For my taste it is ok if the root package requires all the 3rd party stuff, so then I only need to prevent to require drupal/composer_manager.