The "drush finder" script should respect drush being called with an absolute path.

[webbj74]

Regardless of what path I specify drush at it tries to use my local vendor folder. Drush should behave like any other command when I specify the full path to a drush install.

If I want to run my local project's vendor/bin/drush I can specify the path.

Also, I shouldn't have to read the source code to discover why drush is behaving weird.

My steps:

1. Drush is acting weird so I check my version

~/src/project$ drush --version
 Drush Version   :  7.1.0

2. I want to update, so I check where drush is installed

~/src/project$ which drush
/Users/jonathan.webb/.composer/vendor/bin/drush

3. Ok, it's my global install, lets update.

~/src/project$ composer global require "drush/drush:~8"
Changed current directory to /Users/jonathan.webb/.composer
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating drush/drush (dev-master c0212b2 => 8.0.3)
    Checking out ee77dc526aa9fb26611ded18b5caef801b29aca7

Writing lock file
Generating autoload files

4. Verify update worked.

~/src/project$ drush --version
 Drush Version   :  7.1.0

5. Uh, something weird. Let me specify the full path

~/src/project$ /Users/jonathan.webb/.composer/vendor/bin/drush --version
 Drush Version   :  7.1.0

~/src/project$ cd ~

~$ /Users/jonathan.webb/.composer/vendor/bin/drush --version
 Drush Version   :  8.0.3

6. HUH??? Use -dv to look under the hood

~$ /Users/jonathan.webb/.composer/vendor/bin/drush -dv --version
Drush preflight prepare loaded autoloader at                         [preflight]
/Users/jonathan.webb/.composer/vendor/autoload.php [0.03 sec, 2.52
MB]
Starting Drush preflight. [0.03 sec, 2.52 MB]                                                                                                                          [preflight]
Loading drushrc "/Users/jonathan.webb/.drush/drushrc.php" into "home.drush" scope. [0.04 sec, 2.53 MB]                                                                 [bootstrap]
Cache HIT cid: 8.0.3-commandfiles-0-3dd3a45718c897ad06b379e022ef0498 [0.06 sec, 2.59 MB]                                                                                   [debug]
Bootstrap to phase 0. [0.21 sec, 7.5 MB]                                                                                                                               [bootstrap]
Bootstrap to phase -1. [0.21 sec, 7.51 MB]                                                                                                                             [bootstrap]
Found command: version (commandfile=core) [0.21 sec, 7.51 MB]                                                                                                          [bootstrap]
Loading outputformat engine. [0.21 sec, 7.51 MB]                                                                                                                          [notice]
Calling hook drush_core_version [0.21 sec, 7.56 MB]                                                                                                                        [debug]
Returned from hook drush_core_version [0.21 sec, 7.56 MB]                                                                                                                  [debug]
 Drush Version   :  8.0.3

Command dispatch complete [0.22 sec, 7.66 MB]                                                                                                                             [notice]

~$ cd src/project

~/src/project$ /Users/jonathan.webb/.composer/vendor/bin/drush -dv --version
Starting Drush preflight. [0.02 sec, 2.67 MB]                                                                                                                          [preflight]
Loading drushrc "/Users/jonathan.webb/.drush/drushrc.php" into "home.drush" scope. [0.02 sec, 2.67 MB]                                                                 [bootstrap]
Cache HIT cid: 7.1.0-commandfiles-0-8d117348384e93556354e4455d6d2d60 [0.04 sec, 2.73 MB]                                                                                   [debug]
Bootstrap to phase 0. [0.18 sec, 7.54 MB]                                                                                                                              [bootstrap]
Bootstrap to phase -1. [0.18 sec, 7.54 MB]                                                                                                                             [bootstrap]
Found command: version (commandfile=core) [0.18 sec, 7.54 MB]                                                                                                          [bootstrap]
Loading outputformat engine. [0.18 sec, 7.55 MB]                                                                                                                          [notice]
Calling hook drush_core_version [0.18 sec, 7.6 MB]                                                                                                                         [debug]
Returned from hook drush_core_version [0.18 sec, 7.6 MB]                                                                                                                   [debug]
 Drush Version   :  7.1.0

Command dispatch complete [0.19 sec, 7.7 MB]                                                                                                                              [notice]

No useful information returned with debugging output. I determined after reading the source, that "drush finder" was calling my project's vendor/bin/drush. WTF.

[greg-1-anderson]

Yes, this has confused me as well on occasion. The intention here is to avoid dependency hell (which may result in unpleasantness if Drush and Drupal 8 have crossed dependency requirements, while still maintaining the convenience of a global Drush.

Note that at the moment, you can use drush status to determine the path to the actual Drush script in use. Also, the Drush finder has a simplified option parser; it understands -d, but not -dv. This should be fixed.

There should also be a way to disable redispatch (including an environment variable to persistently disable it). Automatically disabling redispatch when $0 contains a full path (or maybe even whenever $0 contains any path separator) would be a good idea. This does open you up to risk of dependency hell, but if you know that your global Drush is the most recent version, and all of your sites are either the latest Drupal 8, or Drupal 7 or earlier, then that won't be an issue. There are certainly use-cases for favoring the global Drush over the site-local Drush -- drush development being a prime example.

Prior to the site-local Drush feature, alternatives similar to php-env were also discussed, but were passed over in favor of the current implementation. Not sure if this maybe should be reconsidered.

[weitzman]

An environment variable to disable redispatch seems reasonable to me.

I'm actually pleased with how this redispatch feature turned out. I think we are avoiding a lot of cross dependency issues for our users. Sadly I don't know of a way to prove that claim. Drush has been around a long time and folks have long used a single global Drush for all their projects. This is a really bad approach in the Composer era. Composer built projects really want Drush to be part of the project so that dependencies are resolved at install time. IMO we need to actively protect end users from themselves here.

I happen to know that both @greg-1-anderson and @webbj74 architect cli tools for hosting platforms. You guys are awesome - and highly non-standard Drush users! You probably want to use your own Drush install and not whatever dreck is in the site's /vendor. That's fine - use Greg's proposed environment variable.

I'm open to further discussion on this. After all, I did get pretty smitten by a much simpler approach proposed at drupal-project.

@webbj74 a bit less WTF and HUH would make your report a friendlier read.

[greg-1-anderson]

Yes, the Drush Finder has the huge advantage of doing the right thing in the average case, and doing Drush development is not a super common usecase for most Drush users. Let's fix the -dv problem, add the environment variable, and auto-set the environment variable when $0 contains a full path, and see how far that takes us.

[weitzman]

I would omit the absolute path item from the first patch. I don't think we should vary behavior on that.

[greg-1-anderson]

So, I'm going to close here, because it is actually destructive to stop Drush from redispatching to a site-local Drush when one exists. The problem is that the global Drush and the site-local Drush, when they are of different versions, are extremely likely to have conflicting dependencies. Moving forward with the global Drush would cause dependency-hell problems, and these are very hard to diagnose and impossible to support.

[phil-s]

The "look in the CWD" behaviour is really terrible. That's exactly like (for this particular command) having . in your PATH (which is likewise asking for trouble).

I can absolutely appreciate looking for a site-local drush in the root of the site being processed; but having the executable called by /path/to/drush -r /path/to/site varying based on the directory I happen to be in at the time? That's awful. Is there a justification for retaining that behaviour?

If people want to run ./drush they can (and should) do exactly that -- explicitly.

I've worked around this in the only way I could see, by setting DRUSH_FINDER_SCRIPT in my drush calls like so:

env DRUSH_FINDER_SCRIPT="/path/to/drush" /path/to/drush -r /path/to/site ...etc...