drush-script for Drush9

[yobottehg]

In one of our projects i updated to Drupal 8.4 and could not find a suitable set of dependencies using composer without updating to Drush9.

Now i'm sitting here and want to update the drush aliases. I looked on #3010 and added following to drush/project.alias.yml:

local:
  root: '/var/www/drupalvm/docroot'
  uri: 'www.project.dev'
  host: 'www.project.dev'
  user: 'vagrant'
  os: 'Linux'
  ssh:
    options: '-o PasswordAuthentication=no -i ~/.vagrant.d/insecure_private_key'
  paths:
    - drush: '/var/www/drupalvm/vendor/bin/drush'
    - drush-script: '/var/www/drupalvm/vendor/bin/drush'

The ssh connection seems to work but the remote side can't find drush. How should i set the pathes?

What is wrong and what do i need to adjust?

for drush @project.dev cr i get the following output:

bash: drush: command not found
Connection to www.project.dev closed.

[joestewart]

I found the same issue that drush-script doesn't seem recognized.

Short term I made sure that a global drush is installed. Drush Launcher can be installed using these settings:

drush_version: "0.4.2"
drush_phar_url: https://github.com/drush-ops/drush-launcher/releases/download/{{ drush_version }}/drush.phar
drush_path: /usr/local/bin/drush

I didn't find a drush bug report yet, but did see that some tests look like they just use "drush" for the executable in drush-script.

EDIT: Need more coffee, this is the drush queue. :)

[greg-1-anderson]

The drush / drush-script configuration items have not been implemented and plugged into backend invoke yet. Help appreciated.

[weitzman]

'drush' is documented as a read only property so not very helpful. I suggest only exposing drush-script.

[greg-1-anderson]

Having both drush and drush-script has always been redundant. Due to different bugs at different times, most folks have been specifying both when it is needed. I suggest that we straighten this out in Drush 9, and implement only drush to behave as drush-script formerly did.

It would also be useful to allow folks to specify a transport command to replace ssh as needed. Some folks are using a similar mechanism in Drupal Console to call straight into a docker container. The Drupal Console solution is an extra-options item which folks have been inserting their docker command into. I am not fond of putting executable paths in an element called options; I also think that we need to keep ssh-options & c. separate, so that options for different transports are not mixed.

My thought was to have a transport item that defaults to ssh for remote aliases, and empty for local aliases. The basename of the transport, sans extension becomes the prefix for the item that contains the extra options, e.g. ssh-options, docker-options and so on. We could evaluate configuration variables such as ${host} et. al. so folks could construct their own transports.

[greg-1-anderson]

Also, it's useful that this issue was added to the Drush queue, as we needed one for this. 😉

[gaelg]

Hi and thanks for working hard on Drush 9 :) I also tried to specify a drush script path in my alias yml file, but I could not find a working syntax. Is this implemented in some way? If not, this issue is not only for Docker, Vagrant, etc. but also for simple remote aliases.

[weitzman]

Lets focus this issue on missing drush-script. The custom transport issue is #1910. I'll copy greg's comment there.

[greg-1-anderson]

Yep, sorry for hijacking this issue.

[yobottehg]

Just wanted to throw in that's currently not possible to use drush aliases on Acquia Cloud with 8.4 and Drush9.

The global installation is Drush8 and Drush9 locally can't be used without the drush-script path to point to the local install.

The drush launcher does not help because it's not possible to install it there.

[greg-1-anderson]

This is definitely on our to-do list. Sorry it didn't make it in for beta6.

Are you able to use the global Drush 8.1.14 with Drupal 8.4 on Acquia, or is a site-local Drush required?

You could try using a global Drush 8.1.14 locally; it should be able to redispatch to a remote Drupal 8.4 with a site-local Drush 9.

[grasmash]

Can we use a policy file to dynamically modify the alias?

/**
 * Implements hook_drush_sitealias_alter().
 *
 * Alter alias record data in code.
 */
function policy_drush_sitealias_alter(&$alias_record) {
  if (!empty($alias_record['remote-host'])) {
    // Set Drush version correctly on Acquia Cloud.
    if (!empty($alias_record['uri'])
      && strstr($alias_record['remote-host'], 'acquia') !== FALSE
      && !empty($alias_record['path-aliases']['%drush-script'])
      && $alias_record['path-aliases']['%drush-script'] == 'drush9'
    ) {
      // Acquia Cloud does not currently support drush9.
      $alias_record['path-aliases']['%drush-script'] = 'drush8';
    }

    // If the alias is "remote", but the remote site is
    // the system this command is running on, convert the
    // alias record to a local alias.
    $uname = php_uname('n');
    if ($alias_record['remote-host'] == $uname) {
      unset($alias_record['remote-host']);
      unset($alias_record['remote-user']);
    }
  }
}

We previously loaded that policy automatically in BLT via drush/drushrc.php. However, drush no longer automatically loads that file. See #3027 and acquia/blt#2105.

[greg-1-anderson]

hook_drush_sitealias_alter does not exist in Drush 9; when it does, it will need to be specified with a @hook annotation, or something similar. Also, note that the structure of the alias file has also changed in Drush 9, along with the name of some elements (e.g. remote-host is now host).

The main problem is that drush-script (or perhaps just drush now) is not being passed from the alias to backend invoke. Until that problem is fixed, it wouldn't do you any good to alter the alias, even if you had a hook to do so.

[greg-1-anderson]

I'm going to implement drush-script as paths.drush-script.