Options when enabling modules via Drush

Hi Brian.

This is great feedback, and I think it is inline with the feature request at #2209089: Resolve the prefer-stable property to provide an option to "--prefer-stable" packages, and we should probably add a corresponding feature to set "--no-dev" so we don't get a lot of extra stuff.

As a workaround for the time being, you can always disable auto-building the composer.json file and installing packages when the app is run on Travis CI and then add a command in .travis.yml to drush composer-manager install --prefer-stable --no-dev to install things as you expect.

Thanks for reporting,
Chris

We are having this problem too, using Behatrunner, its a bit complex due to the use case.

What happens is behatrunner.install uses hook_composer_dependencies_install() to finish its installation routine. That function assumes that all the dependencies have been downloaded.

The flow is something like:

1. behatrunner is enabled
2. user is asked if they wish to download dependencies (in Travis, they probably forced --yes)
3. dependencies download [[ or don't :) ]]
4. behatrunner_composer_dependencies_install() runs, assuming everything is in place, and fails if we're ratelimited.

I suppose there might be a workaround if there is a way to script .travis.yml to enable the behatrunner module, but say 'no' when it asks about downloading dependencies.

Then (hopefully) we could run drush composer-manager install --prefer-stable and behatrunner_composer_dependencies_install() would finish the job.

Ideally we could just set this variable and then enable the module and let it do its thing.

Here's a workaround I have come up with based on #1

install:
  - git clone --branch 8.x-1.x http://git.drupal.org/project/composer.git ~/.drush/composer

before_script:
  - drush si ...
  - drush vset composer_manager_autobuild_file 0 -y
  - drush vset composer_manager_autobuild_packages 0 -y
  - drush en composer_manager -y
  - drush composer-manager install -n --prefer-source                                                                                                                                                                                

Might not work for every scenario. In the case of modules using hook_composer_dependencies_install() we have to do this instead:

install:
  - git clone --branch 8.x-1.x http://git.drupal.org/project/composer.git ~/.drush/composer

before_script:
  - drush si ...
  - drush vset composer_manager_autobuild_file 0
  - drush vset composer_manager_autobuild_packages 0
  - drush en composer_manager -y
  - drush composer-manager install -n --prefer-source
  - drush vset composer_manager_autobuild_file 1
  - drush vset composer_manager_autobuild_packages 1
  - drush en behatrunner -l http://127.0.0.1:8080 -y

We provided a composer.json with the dependency to drupal/drupalextension in our install profile so that behatrunner's libraries get pre-installed during drush composer-manager install.

When behatrunner is enabled, it will see the dependencies are already in place ("Loading from cache" avoids downloading them via dist) and hook_composer_dependencies_install() should then run correctly.

Not elegant, but the best we can do until this issue is moved along or github fixes its ratelimit problems.

Its also worth noting that using --prefer-source has extended our build time by about 15 minutes. So not really an idea solution.

Also seeing a problem attempting to install composer_manager and behatrunner on Jenkins. Installing the packages never completes due to out of memory issues. Installing the composer packages with a similar method mentioned above has allowed the scripted install to work.

Brantwynn, this may or may not be a good method but part of my CI script includes placing the composer.lock file in sites/default/files/composer/ and then running 'composer install' which very quickly installs the needed libraries. That, combined with turning off composer_manager_autobuild_file and composer_manager_autobuild_packages makes for a very quick build and no memory issues.

I've documented this situation for 8.x-1.x under "Drush integration":
https://www.drupal.org/node/2405811