Drush tries to bootstrap the SUT site when installed standalone (out of a Drupal install) via composer

[jonhattan]

To Reproduce

$ cd /tmp
$ composer require drush/drush
$ vendor/bin/drush

PHP Warning:  require(/tmp/vendor/drush/drush/sut/../vendor/autoload.php): failed to open stream: No such file or directory in /tmp/vendor/drush/drush/sut/autoload.php on line 14
PHP Fatal error:  require(): Failed opening required '/tmp/vendor/drush/drush/sut/../vendor/autoload.php' (include_path='.:/usr/share/php') in /tmp/vendor/drush/drush/sut/autoload.php on line 14

Workaround

An installation based on git clone + composer install works as expected.

System Configuration

Q	A
Drush version?	9.x
Drupal version?	-
PHP version	7.1
OS?	GNU/Linux

[weitzman]

I guess thats a global drush9, which technically isn't supported. But I'll see what we can do here. In the meanwhile, you can also workaround this by pointing at your Drupal site with --root or a site alias.

[jonhattan]

drupal-finder uses the installer-paths to find a drupal site: https://github.com/webflo/drupal-finder/blob/master/src/DrupalFinder.php#L106

In this recent commit f7fd4b7, part of #3682 the installer-paths for the SUT were moved to the composer.json

I can't figure out all of this yet. Still investigating.

[jonhattan]

@weitzman thanks. Yes it is a global install, and --root or site alias works.

Confirmed this is not an issue in release 9.4.0, before #3682.

Also, I've found that commenting out https://github.com/drush-ops/drush/blob/master/src/Preflight/Preflight.php#L331 ($fallBackPath = $this->preflightArgs->selectedSite(DRUSH_COMMAND);) it also works.
This line was added in commit 69185f1 and I guess it is neccesary for the case outlined in the commit message.

[greg-1-anderson]

Drush is now requiring Drupal in require-dev for testing purposes. As a workaround, try:

composer require --no-dev drush/drush

[weitzman]

#3746 seems to fix the problem.

[weitzman]

We will also merge #3747 for even more fix.

[weynhamz]

I am still having this problem.

I am installing drush globally in a puppet recipe with below commands

composer init -n --require=drush/drush:9.x-dev
composer install --no-dev

drupal-finder uses the installer-paths to find a drupal site: webflo/drupal-finder:src/DrupalFinder.php@master#L106

In this recent commit f7fd4b7, part of #3682 the installer-paths for the SUT were moved to the composer.json

I ended up with same finding, drupal-finder use 'installer-paths' in composer.json to locate a possible Drupal root, where 'sut' related paths in 'installer-paths' match the criteria.

But due to the way drush is installed, sut would not find the autoloader it wants to.

[weitzman]

I saw this too recently. Until its resolved (or marked won't fix), I recommend you install drush-launcher instead of global drush per drush's install instructions.

You could alternatively pass --root or a site alias so Drush does not guess the root.

[weynhamz]

@weitzman Thanks, followed your suggestions, I have installed drush8 phar and drush9 launcher, but seems now drush8 will automatically use drush9 if it is composer required?

[greg-1-anderson]

@weynhamz It is a feature of Drush that any version will re-launch the site-local (composer required) Drush if it is present. If Drush did not do then, then the dependencies of two different versions of Drush would be mixed. This might sometimes work, but would often fail in strange and difficult-to-diagnose ways.

[weynhamz]

Yeah, right, I understand it now, but I really do not like this implicit way of doing things, especially, when I have drush 8 phar and drush 9 launcher both installed, and I am using drush8 explicitly, and it, in turn, it uses the local drush 9, which is often annoying, and worse if happens in a script.

Sounds like it is more like a design decision issue, it might be better to just bail out if a global drush finds a local higher version exists, then provide an option/flag to drush 8 and allow user explicitly saying that I am okay to use a local version if one found.

[greg-1-anderson]

Breaking scripts rather than redispatchng to the site-local Drush seems unhelpful. We could log a warning when the major version does not match.

[weynhamz]

Is there a way to explicitly disable this using local drush feature, because on my setup, after removing local vendor/drush, drupal8.phar works just fine.

[greg-1-anderson]

Remove the local Drush if you do not want to use it. If it is present, Drush must use it. Note that the most stable configuration is a local Drush that you call directly (try putting vendor/bin at the head of your $PATH). The global Drush may develop problems over time. We will always strive to fix anything that may crop up, but at some point it might not be possible.

[weynhamz]

Yeah, removing local vendor drush works, but for some environment, vendor directory is read-only, and you are struggling to use drush8 to get something done, so a way to explicitly disable including local drush would be an escape hatch.

[greg-1-anderson]

If you need to sometimes use Drush 8, then you should completely remove Drush from your project. Disabling the local Drush is not possible, because all of Drush's dependencies are in the site's vendor directory, so you'd be mixing different versions of the same libraries when you loaded Drupal's autoloader.

[greg-1-anderson]

Reported issue fixed by #3942.

Side issue of disabling a site-local Drush (e.g. when there is a version mismatch) is a "won't fix", because that would cause all sorts of problems due to dependency-hell mismatch between different versions of Drush.