The attached patch demonstrates a modern cli command that will work with future versions of Drush and Drupal Console. Works today with patched versions of both Drupal Console and Drush. Note that this command does not need to directly reference any Drush or Drupal Console APIs.

The roadmap / plan is described in the Drush PR. The general idea is to offer a very simple way to provide a cli interface for module commandline tools that supports loosely-coupled code (does not require a lot of cli-framework-specific code) that works in both Drush and Drupal Console.

The interfaces and search paths are not final yet, and are likely to change. It would be best to keep this PR open until such a time as the Drush and Drupal Console PRs are merged. I will update the patch here as necessary to keep up with changes in the tools.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greg.1.anderson created an issue. See original summary.

jibran’s picture

Thank you @greg.1.anderson nice work with Drush, DrupalConsole, Robo and AnnotationCommand. I'm happy to keep this open and once we are done we can remove the existing drush code form the repo. We can also write some unit test for this class as well. ;-)

greg.1.anderson’s picture

Issue summary: View changes
andypost’s picture

+++ b/src/CliTools/DefaultContentCommands.php
@@ -0,0 +1,56 @@
+     * @param string $entityId The id of the entity to export.
...
+    public function defaultcontentExportReferences($entity_type_id, $entity_id, $entity_type_folder)

this argument optional, we used to allow export all entities when no second argument

greg.1.anderson’s picture

Just a note that the Drupal Console team did not like the new proposal. I am working on improvements that will hopefully be more palatable to all. I'll post an update here when ready.

greg.1.anderson’s picture

We have made some progress, and I have three more patches to share.

The first is an example of annotated command handlers. We still have multiple annotated commands in a single class file; the big difference is that we are now using tagged services to declare where our command handler classes are. The advantage of using tagged services is that now we can use dependency injection to get references to our services, so that we can avoid using the DI container from within our module implementation. We could also inject \Drupal::entityQuery() here -- I just didn't take the time to do that. This should be done before finishing up here.

Drupal Console did not accept the PR for this, so this patch is just an example of what is possible with annotations. This does work with Drush, using as-of-yet unmerged PRs for both the 8.x and master (9.x) branches.

greg.1.anderson’s picture

The next version extends AnnotatedCommand rather than using a command handler class. We are still using tagged service discovery. Note that these *are* Symfony Console commands; we are just using annotations to configure them.

greg.1.anderson’s picture

The final patch shows a straight Symfony Console command. This is also using tagged services for command discovery. This implementation should work equally well in both Drush and Drupal Console once the respective PRs land in each project.

dawehner’s picture

Nice work!

andypost’s picture

Looks cool!
Just needs a bit of code styling and drush support merged

greg.1.anderson’s picture

Here's an update with a couple of minor issues fixed, and a demonstration of using a logger in the default-content-export-references command.

greg.1.anderson’s picture

As a follow-up / update, the Drush and Drupal Console maintainers agreed that something akin to the straight Symfony Console command shown in #8 should be supported in Drush and Drupal Console. Both #8 and #11 are already supported in the latest dev branches for Drush 8 and Drush 9, although we still need to do a tagged release. I also need to review with the latest dev of Drupal Console and see what still needs to be supported there, and submit a PR or two there if needed.

I find the use of a PSR-3 logger to be a very useful to provide a uniform interface to bridge code used by both cli and web clients, but there is still some controversy here, e.g. in the example in #11, while you may want to see progress each time through the loop in the cli tool, you probably don't want that much information in, say, your watchdog log, so the semantic meaning of the PSR-3 interface is not uniform between these two clients. While this is resolvable by selectively providing a PSR-3 adapter object as needed, this particular use is not as clean or unambiguous as one might like, so I don't know that we will be recommending #11 universally.

larowlan’s picture

Note #2758847: Drupal Console commands - can we collaborate towards the best solution?

avibrazil@gmail.com’s picture

I can see there are 2 work streams to integrate this with Drupal Console. Which one is the best and most current and official? Which version of code of each component should I use? The -dev? The Git? The attached patches? Against which version of what ?

I just want to export and import content between sites:

site1> drupal export:.... > artifacts.yml

site2> drupal import:.... < artifacts.yml

Thank you

greg.1.anderson’s picture

The patch here works with Drush 8 and Drush master. The patch at #2758847 works with Drupal Console. We are still working out a strategy to unify these approaches.

andypost’s picture

Btw drush 8.1.3 released and new supports annotated commands
So probably current patch should be updated?!

I see no reason to register commands in container if it possible to discover them with annotations

PS: Related to console integration #2786795: DrupalConsole integration breaks Drush looks console has the same issues

  1. +++ b/default_content.services.yml
    @@ -2,3 +2,18 @@ services:
    +  default_content.export.command:
    +    class: Drupal\default_content\Command\ExportCommand
    +    arguments: ['@default_content.manager']
    ...
    +  default_content.export_references.command:
    +    class: Drupal\default_content\Command\ExportReferencesCommand
    +    arguments: ['@default_content.manager', '@logger.channel.default']
    ...
    +  default_content.export_module.command:
    +    class: Drupal\default_content\Command\ExportModuleCommand
    +    arguments: ['@default_content.manager', '@module_handler']
    

    Any reason to keep this in container all the time?

  2. +++ b/src/Command/ExportCommand.php
    @@ -0,0 +1,73 @@
    + * @file
    
    +++ b/src/Command/ExportModuleCommand.php
    @@ -0,0 +1,62 @@
    + * @file
    
    +++ b/src/Command/ExportReferencesCommand.php
    @@ -0,0 +1,82 @@
    + * @file
    

    not needed

  3. +++ b/src/Command/ExportCommand.php
    @@ -0,0 +1,73 @@
    +
    +class ExportCommand extends Command
    
    +++ b/src/Command/ExportModuleCommand.php
    @@ -0,0 +1,62 @@
    +
    +class ExportModuleCommand extends Command
    
    +++ b/src/Command/ExportReferencesCommand.php
    @@ -0,0 +1,82 @@
    +
    +class ExportReferencesCommand extends Command
    

    there's no annotation?

badjava’s picture

Sorry, didn't see this issue. I posted a new patch on #2912723: Add Drush 9 support.

andypost’s picture

Status: Needs work » Fixed

The leftover is console command issue #2758847: Drupal Console commands

Drush 9 landed in Alpha 7

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.