-
Notifications
You must be signed in to change notification settings - Fork 53
drush_extras can cause provisioning to fail (D8 + Composer) #310
Comments
Good spot. I guess the simplest solution here is to not include it by default. All in favour? |
I'd almost prefer a d8 toggle somewhere. I feel like for 7, having |
OK. This is very much related to #305 in that case. |
For the time being I think it's simplest to just remove registry_rebuild from the defaults. The way Drush commands are now handled in Vlad makes it possible to re-add registry_rebuild via the vlad_settings.yml file, just set the relevant variable to include the commands you want installed (code copied from the current drush_extras role's default vars file):
In the short term, I'd rather introduce this minor inconvenience for when working with D7 sites in order to prevent an outright provisioning fail in the scenario you describe for D8. Hopefully, as ideas solidify over at #305 we can look at having different defaults for D7/D8 and re-introduce registry_rebuild as a default for D7. |
In fact, looking at the defaults, it looks like it may be wise to remove the version from the entry for coder. |
- Fixes #310. - Now more D8 compatible.
Since it was the default before, would it make sense to add it to the example settings if it's not going to happen automatically? |
In a scenario where you're using a new VM, with an existing drupal 8 install, and where drush is included in the composer build for that drupal 8 project, the default configuration for
drush_extras
will cause provisioning failure, asregistry_rebuild
doesn't have a working d8 version. And even if it did, including it by default for d8 is of arguable utility since d8'sdrush cr
includesdrush rr --fire-bazooka
, essentially.However, attempting re-provision will work successfully after it has failed once.
The text was updated successfully, but these errors were encountered: