Tonight I was reading up on the history of the Drupal Console. It started after seeing a tweet that seemed to indicate that the Drupal Console project is headed towards full command-line abilities to control Drupal. Up until recently, the Drupal Console has been described mostly as a "scaffolding tool" for Drupal 8, which would help save developers from boilerplate code. But Console can now enable/disable maintenance mode, which looks like it's headed right into full-blown site management.
This got me thinking, "don't we already have a command line tool for managing Drupal?" Of course we do! It's drush, The canonical tool for managing Drupal sites. I know I must not be the first to think of the overlap, and knowing the Drupal community tends to react poorly to overlap, I did some searching on the history of these two projects. There are a lot of cross-links that happen all over the place, but I think these two posts generally sum things up:
- The first post suggesting Drupal Console overlaps and should merge with Module Builder: https://www.drupal.org/node/2298437
- The issue for using Symfony's Console component directly within Drush: https://github.com/drush-ops/drush/pull/88
It may take a while to read through the posts and their internal links, but several similarities struck me between Drush/Console and Drupal/Backdrop.
- The initial reaction was negative. Both Backdrop and Drupal Console received some negative response, claiming that the overlap was wasted work or would hurt either the project or developers.
- The purpose for forking or rewriting was based around leveraging Symfony components. I find this interesting that Backdrop was created to avoid adopting Symfony, which in turn led to major refactoring and rewriting of major systems. In this case, Drupal Console could (loosely) be considered the fork for the opposite reason. Drush maintainers considered some Symfony underpinnings but decided (for now) that the amount of change and syntax differences didn't really warrant implementation. Drush stayed the same (a la Backdrop) but Drupal Console adopted Symfony components (a la Drupal 8).
- Symfony's paradigms infect all code it touches. I know "infect" is a negative term, but being a proponent of the infectious GPL license, I don't necessarily think of it in a negative light. Drupal 8 didn't set out to rewrite all its subsystems, but after adopting Symfony at the bottom-most layer, the concepts bubbled up into higher levels of the application. It seems to me that the fundamental incompatibility between procedural programming and dependency-injection leads in inevitable rewriting of all code so it fits with the dependency-injection model.
- There are differences in compatibility. Moving from Drush to Console (if you were so inclined) will almost certainly require rewriting scripts and integrations, but Drush 7 to Drush 8 likely will be very compatible. On the opposite side, the jump from Drupal 7 to Drupal 8 requires significant rewriting, while moving from Drupal 7 to Backdrop maintains most compatibility.
- Even though there's now a split, both projects are still communicating and moreover, collaborating on solving problems. I think it's wonderful that the Drush and Console folks have had no hostility. Instead you see the opposite, that they're cross-communicating ways that each could leverage from the others approach. Backdrop and Drupal are collaborating in similar fashion, such as coordinating security releases and cross-porting patches/pull-requests between the projects.
So with all these comparisons, you can see that it's not simply an analogous "A is to B as C is to D" situation, but there are a lot of similarities between reactions, purpose, and intent. As Mark Ferree said, it'll be interesting to see where both projects end up.