Upgrade Drupal VM to use Drush Launcher / drush role 3.0.0 version

[geerlingguy]

Issue Type

• Feature Idea

Summary

Drush 9 and Drupal 8.4 have thrown a bit of a wrinkle into the Drush-based Drupal automation world... there are some backwards-incompatible breakages that make working with older and newer sites at the same time a little awkward.

The geerlingguy.drush role was just updated to 3.0.0 (see geerlingguy/ansible-role-drush#44 (comment) for a brief overview of the new features), and the Drush integration in Drupal VM will need to change at least a little bit to get things working well with the latest role version.

Basically, the 3.0.0 version installs Drush Launcher by default (instead of global Drush from a .phar file), because that's the recommended way to use the drush command system-wide, especially with Drush 9+.

This means we'll have drush available, but it will only work in the context of a Drupal project with Drush as a dependency. Also, the alias files will need to be changed to work properly with Drush 9+... so we might want to either write two sets of alias files if aliases are enabled (one for < 9, one for 9+), or determine the Drush version somehow and write the correct type of alias file?

See related: #1595 — I might move the Drush aliases work to that issue, since just getting things working with Drush Launcher instead of system-wide Drush could take a little time.

Remaining Tasks

• Upgrade geerlingguy.drush role to 3.0.0 (so we install Drush Launcher by default).
• Remove the default drush_version variable from the default config.
• Ensure site installation still works via the installed site-local version of Drush.
• Update documentation to mention how you can get a specific version of Drush globally installed via Composer (well sorta-globally—to one user), and how you can install via source for a truly global install.
• Update documentation anywhere it mentions Drush alias management.
• Write a blog post detailing the major architectural shifts required to move to Drush 9.0.0... and why Drupal VM is making that move. And how to un-make it if your project still requires an older version!

[geerlingguy]

Going to release 4.7.2 bugfix release before beginning work on this: #1673

[geerlingguy]

So just switching to 3.0.0 seems to work fine in terms of getting the site-install command working (at least inside the VM).

Also, if I have Drush 8.1.15 installed on host, the current (old style) Drush aliases seem to work to connect to Drush inside the VM at version 9.0.0. (cc @danepowell).

Inside the VM, after I run vagrant ssh to log in, I can run drush status successfully quite well:

vagrant@drupalvm:/var/www/drupalvm/drupal/web$ drush status
 Drupal version   : 8.4.4                                                 
 Site URI         : default                                               
 DB driver        : mysql                                                 
 DB hostname      : localhost                                             
 DB port          :                                                       
 DB username      : drupal                                                
 DB name          : drupal                                                
 Database         : Connected                                             
 Drupal bootstrap : Successful                                            
 Default theme    : bartik                                                
 Admin theme      : seven                                                 
 PHP binary       : /usr/bin/php7.1                                       
 PHP config       : /etc/php/7.1/cli/php.ini                              
 PHP OS           : Linux                                                 
 Drush script     : /usr/local/bin/drush                                  
 Drush version    : 9.0.0                                                 
 Drush temp       : /tmp                                                  
 Drush configs    : /var/www/drupalvm/drupal/vendor/drush/drush/drush.yml 
 Install profile  : standard                                              
 Drupal root      : /var/www/drupalvm/drupal/web                          
 Site path        : sites/default                                         
 Files, Public    : sites/default/files                                   
 Files, Temp      : /tmp

Running drush status bare, outside of a webroot, understandably gives:

vagrant@drupalvm:/var/www/drupalvm$ drush status
The Drush launcher could not find a Drupal site to operate on. Please do *one* of the following:
  - Navigate to any where within your Drupal project and try again.
  - Add --root=/path/to/drupal so Drush knows where your site is located.

But running drush --root=/var/www/drupalvm/drupal/web status works the same as running it within the webroot.

So, primarily, this will be an educational thing, with the following lessons learned (so far):

1. Starting with the next version of Drupal VM, because it uses Drush Launcher instead of a global Drush install (because that's the way of things with Drush 9), you will always need to run drush commands in a Drupal web root with a codebase that already has Drush installed as a Composer dependency, or you have to pass the --root option like drush --root=/path/to/drupal/webroot.
2. You can still install Drush globally inside the VM, using the other install options provided by geerlingguy.drush, but this is not recommended or the supported method of using Drush with Drupal VM any more.
3. I'm going to have to rework the Drush alias situation for Drush 9.0.0 on the host machine (inside the guest things seem fine, but outside, right now Drupal VM only officially supports 8.1.15 on the host since it works with the generated Drush alias file). See Drush 9 cannot SSH into Drupal VM #1595 for details and further work.

Basically, if you've been putting off using Composer to manage your Drupal site's codebase (either for 7 or 8!), and want to continue using Drush, consider this the third or fourth major impetus towards making that change!

You can always decline using Drush entirely, and remove it from your installed_extras, too (note that the automatic Drupal installation option won't work if you do that).

[geerlingguy]

Wrapping the postgresql install issue that's been breaking builds for a week into #1675 :(

[geerlingguy]

Also sooner or later we need to Remove Drush make support :( — so opened a new ticket for that too.

[geerlingguy]

Also slightly related: drush-ops/drush-launcher#2

[geerlingguy]

Wrote the blog post, waiting to publish it until I finish testing and merge this branch... and create 4.8.0.

[geerlingguy]

Done. This is in master, next step is to create a 4.8.0 release.

[mminklet]

This is causing us some difficulties on a project that we can't upgrade to drupal 8.4 yet, and also can't install drush locally due to dependency hell in composer. I'm trying to figure out how to get previous functionality of the drush ansible role, ie to specify a drush version <9 and not install the launcher. Is this still possible?

[teknikqa]

Just add these two lines to a post-provision script. This will add Drush globally, which the Drush launcher will use as a fallback if it does not detect drush in your project.

composer global require drush/drush:~8.0
export DRUSH_LAUNCHER_FALLBACK=~/.composer/vendor/bin/drush

The only issue that I have faced is with composer running out of memory. But that can be fixed by increasing the memory of the VM or by running composer global update a few times.

[mnovbaalen]

I'm using DrupalVM for developing Drupal 7 and 8 applications.
For the Drupal 7 projects, which are not composer managed, I use the solution given in these posts:

webflo/drupal-finder#35
drush-ops/drush-launcher#45

This installs drush in my Drupal 7 projects.

Because I don't want the composer.json and .lock files and vendor files in Git, I've added these to .gitignore, so my Git repository remains unchanged.