Debian wheezy support broken by drush dependancy

[ol0lll]

Drush depends on d11wtq/boris which in turn depends on ext-readline (since d11wtq/boris 1.0.9). This (php5-readline) is not available on debian wheezy. I know that it is possible to use packages from dotdeb.org but I don't think this is a viable approach for production environments.

[greg-1-anderson]

Maybe we should split the Drush core-cli command into a separate package; we could then 'suggest' this package from Drush core's composer.json.

http://php-and-symfony.matthiasnoback.nl/2014/04/theres-no-such-thing-as-an-optional-dependency/

[weitzman]

The author of that article makes some good points, but suggest is just informational. You don't even get help on what version to install. See https://github.com/composer/composer/issues/510.

[greg-1-anderson]

Yes. To spell out more completely what was suggested in the article:

We would make a new package 'drush/cli' (or something), which would contain the implementation for the 'core/cli' command. The composer.json for drush/cli would require d11wtq/boris (with an applicable version number). 'drush/drush' would then suggest 'drush/cli'.

There are downsides to this, of course. We might need to make 'drush/cli7' and 'drush/cli8' to work around the limitations of 'suggest'. Hm, composer can be quite a mess!

Maybe the core-cli command needs to be an ordinary Drush extension -- kick it out of core, and put it on drupal.org so that it can be fetched with 'drush dl'?

Seems like a lot of hassle. It seems tempting to just say that we should punt -- drush requires what drush requires -- but core-cli seems awfully optional compared to the situation where you just want to install Drush on a production server, and you don't have all of the required packages yet. This to me implies that core-cli should be an optional component.

[weitzman]

We have had core-cli in Drush for a long time and this is first time someone complained about its dependencies. Lets break it out if the chorus gets louder.

[greg-1-anderson]

I agree that we should punt for now, as composer makes "optional requirements" messy. (I don't agree that there is no such thing as an optional dependency -- the concept is fine, it's just not supported very well by Composer.)

However, I will also mention here that core-cli was not in Drush 6, so it was only recently that we had a dependency on php5-readline in a stable release of Drush. In the near term, folks can use Drush 6 in production, and this should not cause much of an issue, e.g. if they are using Drush 7 or Drush 8 locally.

[geerlingguy]

Note that there is a workaround—you have to first clone drush, then within the directory, manually install version 1.0.8 of boris (sudo composer require boris:1.0.8 - which does install on Debian Wheezy), then run composer install for the rest of the dependencies. As long as you don't use the drush cli component, everything works fine.

It's hacky, can't really be automated as easily (since this would have to be done specifically for Drush only on certain environments), but it at least lets me install and use Drush on a Raspberry Pi ;-)

There was some upstream issue in the boris repo, can't find it now, but this same issue has cropped up in many places:

• https://github.com/laravel/framework/issues/8136
• https://github.com/borisrepl/boris/issues/103
• https://github.com/geerlingguy/raspberry-pi-dramble/issues/48

According to the boris devs, it was just a missing dependency in the 1.0.x branch, but imo, they should've bumped at least the minor version for the change, since it does, in fact, break a bunch of other projects :P

[greg-1-anderson]

Should we consider changing Drush to require boris:1.0.8? Any major functionality that would be missing or lost for drush cli users?

[vmiimu]

Details regarding my workaround to install Drush on Debian Wheezy in case it can help others.

Initially I couldn't install Drush on Debian Wheezy:

uname -a
Linux zero 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux

curl -sS https://getcomposer.org/installer | php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /home/vmi/composer.phar
Use it: php composer.phar

sudo mv composer.phar /usr/local/bin/composer
sudo ln -s /usr/local/bin/composer /usr/bin/composer
sudo git clone https://github.com/drush-ops/drush.git /usr/local/src/drush
cd /usr/local/src/drush
sudo git checkout 7.0.0
sudo ln -s /usr/local/src/drush/drush /usr/bin/drush
sudo composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for d11wtq/boris v1.0.10 -> satisfiable by d11wtq/boris[v1.0.10].
    - d11wtq/boris v1.0.10 requires ext-readline * -> the requested PHP extension readline is missing from your system.
drush --version
Unable to load autoload.php. Drush now requires Composer in order to install its dependencies and autoload classes. Please see README.md

I ran composer update before running composer install:

sudo composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing symfony/process (v2.4.5)
    Downloading: 100%

  - Installing d11wtq/boris (v1.0.8)
    Downloading: 100%

  - Installing symfony/var-dumper (v2.7.1)
    Downloading: 100%

  - Installing pear/console_table (1.2.1)
    Downloading: 100%

  - Installing sebastian/version (1.0.5)
    Downloading: 100%

  - Installing sebastian/global-state (1.0.0)
    Downloading: 100%

  - Installing sebastian/recursion-context (1.0.0)
    Downloading: 100%

  - Installing sebastian/exporter (1.2.0)
    Downloading: 100%

  - Installing sebastian/environment (1.2.2)
    Downloading: 100%

  - Installing sebastian/diff (1.3.0)
    Downloading: 100%

  - Installing sebastian/comparator (1.1.1)
    Downloading: 100%

  - Installing symfony/yaml (v2.7.1)
    Downloading: 100%

  - Installing doctrine/instantiator (1.0.5)
    Downloading: 100%

  - Installing phpdocumentor/reflection-docblock (2.0.4)
    Downloading: 100%

  - Installing phpspec/prophecy (v1.4.1)
    Downloading: 100%

  - Installing phpunit/php-text-template (1.2.0)
    Downloading: 100%

  - Installing phpunit/phpunit-mock-objects (2.3.4)
    Downloading: 100%

  - Installing phpunit/php-timer (1.0.6)
    Downloading: 100%

  - Installing phpunit/php-token-stream (1.4.3)
    Downloading: 100%

  - Installing phpunit/php-file-iterator (1.4.0)
    Downloading: 100%

  - Installing phpunit/php-code-coverage (2.1.6)
    Downloading: 100%

  - Installing phpunit/phpunit (4.7.4)
    Downloading: 100%

d11wtq/boris suggests installing ext-readline (*)
symfony/var-dumper suggests installing ext-symfony_debug ()
pear/console_table suggests installing pear/Console_Color2 (>=0.1.2)
sebastian/global-state suggests installing ext-uopz (*)
phpdocumentor/reflection-docblock suggests installing dflydev/markdown (~1.0)
phpdocumentor/reflection-docblock suggests installing erusev/parsedown (~1.0)
phpunit/php-code-coverage suggests installing ext-xdebug (>=2.2.1)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
Writing lock file
Generating autoload files

Then drush installs fine:

sudo composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
drush --version
 Drush Version   :  7.0.0

[greg-1-anderson]

The above implies that a newer version of Boris suggests rather than requires readline. If we just ran composer update and checked in the new composer.lock, things would be easier for folks.

[geerlingguy]

@greg-1-anderson - If that's possible, that would be greatly preferred. I hate the idea of hacking all the drush-related installation scripts and ansible playbooks I maintain to do something special just for Debian 7.

[greg-1-anderson]

Just looked at this more closely. The composer.lock in Drush uses Boris 1.0.10, but the composer update run above gives Boris 1.0.8 -- an older version that suggests rather than requires readline. I did not investigate why this should be the case, but Drush itself requires any 1.x version of Boris, so the exact version that is retrieved must be a function of not only what is available, but on other constraints supplied by other components that are O.S.-specific (i.e. perhaps Debian has some component that limits Boris to 1.0.8.)

However, per the bug report quoted above (https://github.com/borisrepl/boris/issues/103), the Boris 1.0.8 workaround is not great, because Boris itself does not work unless readline is installed. So, if we did change Drush to require Boris 1.0.8, we would also need to test for the availability of Boris' "optional" requirements, and not allow core-cli to run in those instances. In addition to this, we'd be excluding any bugfixes and improvements in Boris 1.0.9, 1.0.10, and all future versions on the 1.x line. The full impact of this is impossible to predict.

I therefore do not think this is a good workaround; better to break out all of Drush core-cli into a separate component (as we just did for config-merge), which could itself require Boris ~1.0.

Closing this again, per Moshe's original comment.

[geerlingguy]

@greg-1-anderson - In that case, do you have a timeline for when core-cli would be broken out into a separate component? I'm trying to decide if I should add a hack to my scripts so I can get Drupal 8 running on Debian 7 more easily, or if I should wait until this issue is resolved upstream :)

[geerlingguy]

For posterity: #1420

[weitzman]

core-cli is a thin wrapper around boris. There is no reason beyond this issue to break it into its own component. I'd just as soon keep the issues and git history in one github repo, and so on.

[geerlingguy]

Makes sense; if we're going that route, then there is no way to use Drush with Drupal 8 on Debian 7 without the hack of manually installing/requiring Boris 1.0.8 for now. It's not ideal, but I'd rather know that's the reality than expect that something will change in the near future :)

[geerlingguy]

And FYI, it looks like running composer update before composer install in the drush directory does, in fact, allow Drush to complete installation on Debian 7 Wheezy.

[DeveloperChris]

composer update did not work for me on debian 7 wheezy. What it did do is install a whole bunch of packages and still complained about readline being absent, I have no idea what the extra packages are for and whether they represent a security risk or not.

I don't have the time to follow down every security path for all these packages. For me this crosses drush of my list of go to tools. it was handy but not THAT handy.

Ok My bad. The reason it failed was a bad symbolic link (I had assumed it was the missing readline). but as I still cannot spend the time researching all these packages. The result is the same.

[greg-1-anderson]

Summary of workaround to install Drush 7 on wheezy:

cd /path/to/drush
sudo composer require boris:1.0.8
sudo composer update
sudo composer install

Then, Drush 7 will work, as long as you do not use the core-cli command.

[DeveloperChris]

Thanks Greg I appreciate the response.