-4

If I'm not wrong about 4 or 3 years ago Drush was combined with composer, then it was "decombined" with it, till Drush 9 when they were recombined.

If I'm accurate, why did this combine-decombine-combine process take place and is it likely it will again be decombined?

Update

By "combined" I meant that Once I could do trivial tasks like updating my site via Drush (with pm), than (AFAIR) composer was combined with it and than I couldn't, and then it was de-combined and I could again, but since Drush 9 it was re-combined so I can't (pm is no longer supported for updating core, modules and themes), unless I composerize my Drupal app, then do it with a Composer-Drupal command.

Maybe it weren't the developers who went back and forth. Maybe in Drupal 8 pm was always disabled and it was just a small period of time when I worked with D8, then D7, then (were finally more modules were ready) got back to D8, hence I mistakenly think that the developers themselves took away pm then brought it back.

5

In the past there were a lot of tutorials about how to install a stand alone Drush globally via Composer. These are no longer valid. You simply download a phar file of Drush 8 and that's it, as described in Install/Upgrade a global Drush.

The install method of Drush 8 or previous versions is not connected to the new concept of Drush 9.

A composer based Drupal installed by composer create-project drupal-composer/drupal-project includes Drush 9 locally by default and this is the only recommend way to use Drush 9. See drupal-composer/drupal-project.

So both current Drush versions are easy to install: Drush 8 for a Drush based, and Drush 9 for a Composer based workflow for maintaining the code base from the command line.

You can run both at the same time from the command line with drush. Drush 8 installed globally in /usr/local/bin/drush and Drush 9 locally in a composer project. Drush 8 acts as a launcher for Drush 9 when you run it from inside of a Drupal 8 project.

  • 1
    @JohnDoea pm (or more pertinently the part of it you’re taking about, downloading modules) was never disabled, indeed it still isn’t. It’s just that more recently (since around Drupal 8.4 if memory serves), a policy exists to stop you using it if your project is managed with Composer. I think you’re conflating several unrelated things here and that’s where the confusion is coming from. Case in point, Symfony, Laravel and Twig have nothing to do with this – Clive Oct 13 '18 at 15:40
  • Not Drupal 8, but Drush 9 has depeacated most pm commands. Like I've explained in the answer Drush 9 is normally part of a composer based project and then you don't need those anymore. – 4k4 Oct 13 '18 at 15:41
3

I must precede the technical answer with some background: In programming there's a concept called scope (which I can simply define as range of actions for some given data, like a variable). It is common to distinguish between global scopes and local scopes (the difference between a global scope and a local scope can often be a bit ambiguous.

A good example is from the DOM-JavaScript paradigm (window scope, document scope, function scope).

Global Drush installation versus local Drush installation

No matter how one installs Drush, we first need to distinguish installing Drush globally (one Drush app for all Drupal apps in a given webserver environment) from installing Drush locally (one Drush app per each Drupal project in such environment).

The importance of Drush scopes:

Quoting Leymannx from the comments:

Imagine you work at a web agency and have to support multiple different Drupal versions. Drupal 6 + 7 requires Drush max. v8, while Drupal 8 requires Drush min. v9. So, you have a lot of old Drupals on your server with a globally installed Drush 8 or older. Because that's how it used to be. Now there's Drupal 8 that requires Drush min. v9. You can't simply replace the old global Drush. And at the same time you don't want to rebuild all the old Drupals from scratch into a Composer project.

And still, you could install multiple global Drush versions and have their commands named drush8 and drush9 for example, like explained here: drupal.stackexchange.com/a/267520/15055

Drush <=8 and Composer

Once there were many tutorials for installing a stand-alone Drush <=8 globally, via Composer (stand-alone means that only Drush is installed on the environment globally - without creating a new Drupal project alongside it), but these tutorials are usually irrelevant nowadays.

If you still want to install Drush 8 globally today, you can simply download a phar file of Drush 8 and that's it (no Composer involved), but it's better to avoid that.

Drush 9 and Composer

Installing Drush 9 is essentially different from installing Drush <=8 in these measures:

  1. It is now a convention not to use Drush globally, rather, locally per each Drupal project.

  2. It is now a convention to install Drush only via Composer, and not just an unconventional choice (neither it is installed from a phar).

  3. A local Drush installed with Composer is not stand-alone, as it comes with a new Drupal project alongside it.

Simply put, Drush 9 is formally Composer-centralized and local-scope centralized (and thus non stand-alone centralized).

Example

A Composer based Drupal project (app) with a local Drush alongside it can be installed by:

composer create-project drupal-composer/drupal-project

Further reading

Regarding the installation and usage of Drush 9 I strongly recommend reading these Drupal Answers sessions:

  1. How to update core and all modules and themes from CLI?
  2. Composer's drupal/drupal versus Composer's drupal/core
  • 1
    Regarding your notes, why a scoping distinction is important: Imagine you work at an web agency and have to support multiple different Drupal versions. Drupal 6 + 7 requires Drush max. v8, while Drupal 8 requires Drush min. v9. So, you have a lot of old Drupals on your server with a globally installed Drush 8 or older. Because that's how it used to be. Now there's Drupal 9 that requires Drush min. v9. You can't simply replace the old global Drush. And at the same time you don't want to rebuild all the old Drupals from scratch into a Composer project. – leymannx Oct 16 '18 at 7:12
  • 1
    And still, you could install multiple global Drush versions and have their commands named drush8 and drush9 for example, like explained here: drupal.stackexchange.com/a/267520/15055 – leymannx Oct 16 '18 at 7:14
  • wow ! Thx dear Leymannx for this clear didactic explanation !!! – JohnDoea Oct 16 '18 at 10:01
  • You can run both with the same command drush. Drush 8 installed globally in /usr/local/bin/drush and Drush 9 locally in a composer project. Drush 8 acts as a launcher for Drush 9 when you run it from inside of a Drupal 8 project. – 4k4 Oct 17 '18 at 16:25
  • 1
    No, this is the way I prefer to run both versions in a mixed environment. – 4k4 Oct 17 '18 at 19:37
0

Drush 9 is upgraded for Drupal 8. Rapid changes and change in the way it works also reflects it continues efforts to be compatible with latest Drupal 8.x APIs.

And here is some information about why it looks like 'Back & forth':

1) Since the last popular version of Drush, Drush 9 builds upon Symfony whereever 'possible'. This is inline with Drupal 8 compatiblity. 2) To manage dependencies, it uses composer to minimize the efforts at user end. 3) You can still use Drush globally. Check the attached screen shot. enter image description here 4) With Drupal 9, Drupal project generation have become very strong. To comply with Drupal 8, now with Drush 9, you can create Drupal 8 projects, module, plugin, entity and even perform a migraiton. 5) Drush makes use of Drupal 8 config system. Now, you can delete any configurations from command line. Just delete the respective configuration object.

If I missed anything, please add it to the list.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.