Call Drupal Console commands natively from Drush #1337
Conversation
…h command records for all Console commands, so that they can be displayed in Drush's help output, and executed. This allows us to run commands such as 'drush @Remote x-generate-module', and remotely run Console commands with a Drush alias. Code is still rough at the moment. Console commands are converted from 'generate:module' to 'x-generate-module' to match Drush command conventions without overlapping with existing Drush commands. This won't be the final transformation, but some discussion will be necessary before we can decide on what it should be.
…require ~0 instead of dev-master. Also, commit composer.lock to passify Travis.
|
Drat. I deliberately did not include composer.lock in the original PR, to avoid a huge number of irrelevant lines in the diff, but doing that caused Travis to have an existential crisis. So, I've added composer.lock to make the tests run -- sorry for the size of the diff. |
…D before $application->run(), to prevent Drush from complaining about the call to exit().
|
I didn't need to worry about including composer.lock in the PR; github is smart enough to hide this file in the diff by default. There are a couple of spurrious failures above, related to cloning the cck_signup project. Everything else is green; onward and upward. |
|
I like that this is the |
greg-1-anderson
changed the title
| @@ -30,7 +30,8 @@ | |||
| "d11wtq/boris": "~1.0", | |||
| "symfony/yaml": "~2.2", | |||
| "symfony/var-dumper": "2.6.3", | |||
| "pear/console_table": "~1.2.0" | |||
| "pear/console_table": "~1.2.0", | |||
| "drupal/console": "~0" | |||
There was a problem hiding this comment.
May I ask why is this required? I think it should be optional or recommended.
There was a problem hiding this comment.
If Drupal Console is required, then it gives us a mechanism to use its code to start migrating Drush commands to the Symfony console. At the moment, though, this PR is just a proof-of-concept. At first, there won't be any Drush commands that require Drupal Console, so we could certainly start off with this as a recommended package.
…e kernel object during the bootstrap configuration phase, and then bootstrap the kernel in the bootstrap full phase.
|
Myself and Jesus from Drupal Console plan to discuss this PR and general collaboration approach during upcoming Drupalcon (mid May). I'll post here after that discussion. |
|
Not sure exactly where best to cross-link this, but trying this one (nice issue ID btw :D). Note that there's an RTBC issue in the Drupal core queue at https://www.drupal.org/node/2493807 to add Symfony Console to D8 core. This is soft-blocking the critical issue about testing 8.x -> 8.x upgrade paths at https://www.drupal.org/node/2447573 which is why it's being considered at this late date for 8.0.0. Not sure if this helps or hurts your efforts but maybe chime in there if you have thoughts! |
|
What I said in https://www.drupal.org/node/2391219 stands: console shouldn't exist because it will force contrib authors to ship console AND drush integration both. As I mentioned there, core hardwires certain things to stop such idiocy -- modules can only ship default extension templates so that noone can demand from contrib authors to ship several templates. Configuration install storage is no longer a service, enforcing everyone to ship YAML configuration. Alas, the project has no tech leadership to enforce such splinter does not happen outside of core. Short of that and short of the webmasters having two brain cells to shut the console project down, this is an absolute critical so that when people file issues to ship console integration the contrib authors can won't fix them and point to drush integration and that's it. |
|
Well, I admit it is kind of regrettable that there are two tools here, but the current state of affairs being what they are, most folks will not be able to help but to use both Drush and Drupal Console when working with Drupal 8. This is going to cause some problems in contrib, but the problem is just going to be that contrib authors are going to have to decide whether to use Drush or Console to implement their cli tools; no one is going to need to write a Drush interface and a Console interface. Still, there are lots of reasons why we should merge Console and Drush. The main ones are:
The solution here isn't to "stop Console". We all owe a lot to the Console project. They have made some really useful tools, and the decision to decouple allowed them to make faster progress than if they had fixed the problems in Drush. As I have mentioned before, we have had the idea / desire to use the Symfony Console component in Drush since before the Drupal Console existed, but no one has been available to finish the hard work that would make that possible. This issue has come a long way to making that a reality, but it is unclear whether, in the end, we as a community are going to do the right thing, or whether we're going to keep doing the easier thing, and make small independent changes to each project. I think that in the beginning, it was the right decision to work independently, but only because we lacked enough volunteer hours to do the hard work, and we needed the capabilities that could be easily provided to the community by making a separate Symfony-based tool. The time has come now, though, to start paying down some of the technical debt, and work on better integration for the tools. There are two more points I want to make in closing:
So, fragmentation is inevitable. The solution is not to try to stop folks from writing awesome tools, but rather to do more of the less-glamorous maintenance work to keep them working well together. We're going to be sprinting at BADCamp; anyone who wants to pitch in is welcome to join us. |
|
The spirit of Free Software is to let authors contribute with freedom, we should not read (yes, I'm using "should" @chx) "don't duplicate efforts" literally. I prefer to say: "don't waste efforts". Should we afford to rewrite Drush for Drupal 8? Drush was a fantastic tool but now is time for a new project: DrupalConsole. Letting Drush integrate with the future is an smart move, less hassle IMHO. My 2c. PS: http://cgit.drupalcode.org/drush/commit/?id=92611ecbcbfe7f6722882bcfa50e6cbcc915c2a5 |
|
I think this is a great move forward. Console supports calling Drush, Drush supports calling Console. Having two tools is a bit maddening, but it's better to piggyback one another than work on the same thing. Drush doesn't provide code scaffolding and Drush does many things Console does not. Fragmentation is a repercussion of progress. At least efforts are being made to simplify the future and abstract components into shared libraries. |
|
See also #2103 |
|
Drush's master branch can now execute Symfony commands. I think thats as close as we are going to get on this one. |
In this PR, we build Drush command records for all Console commands, so that they can be displayed in Drush's help output, and executed.
drush @site x-generate-module.This PR, while still early, is an exciting step forward, and meets many of the goals discussed in #88. It allows folks to write symfony console component commands, and call them from Drush utilizing Drush features (e.g. site aliases, shell aliases, command-specific options, etc.). In the future, the construction of the Symfony application object, currently done in an adapter file (consoleadapter.drush.inc) could instead become part of the core Drush bootstrap, and used natively by Drush commands.