DrupalConsole integration breaks Drush

I'll copy over my comment from the duplicate issue:

Normally, this could be solved by including Drupal Console in the project's composer.json (or better: in metatag's module composer.json, if there's a requirement for having Drupal Console)

However, if I'm adding it to my composer.json as required dependency to include the current version (1.0.0-beta5), I'm getting a different error on drush commands.

"drupal/console": "~1.0",

I needed to run "drush entup", but the command fails with this stacktrace:

TypeError: Argument 1 passed to Drupal\Console\Command\Command::__construct() must be an instance of Symfony\Component\Console\Helper\HelperSet, none given,   [error]
called in /var/www/drupalvm/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 264 in Drupal\Console\Command\Command->__construct() (line
35 of /var/www/drupalvm/vendor/drupal/console/src/Command/Command.php).
TypeError: Argument 1 passed to Drupal\Console\Command\Command::__construct() must be an instance of Symfony\Component\Console\Helper\HelperSet, none given, called in /var/www/drupalvm/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 264 in /var/www/drupalvm/vendor/drupal/console/src/Command/Command.php on line 35
TypeError: Argument 1 passed to Drupal\Console\Command\Command::__construct() must be an instance of Symfony\Component\Console\Helper\HelperSet, none given, called in /var/www/drupalvm/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 264 in Drupal\Console\Command\Command->__construct() (line 35 of /var/www/drupalvm/vendor/drupal/console/src/Command/Command.php).

Update

It's clear, why this is raised: the constructor of \Drupal\Console\Command\Command demands a HelperSet as parameter, which isn't set by dependency injection, as it's not defined as argument in the services.yaml. But I don't think, that that would be possible, as there's probably no service implementing HelperSet to inject here.

The question above all is, why is/was it necessary to define the DrupalConsole commands as service? Is this required by DrupalConsole? If yes, how can this work with dependency injection at all????

And because it's defined as service, it also gets loaded during Drush call. That explains, why the commands are picked up. So if there's a chance to drop the services, but still have working Console integration, you'll get rid of all errors!

I have came across this issue as well. Normally the Drupal Console commands do not need commands as services.

I guess this was to allow using tags, as in:

  metatag_generate_group:
    class: Drupal\metatag\Command\GenerateGroupCommand
    tags:
      - { name: console.command }
  metatag_generate_tag:
    class: Drupal\metatag\Command\GenerateTagCommand
    tags:
      - { name: console.command }

in metatag.services.yml.

When we look at GenerateTagCommand.php in the constructor we can find in the constructor:

  public function __construct($translator) {
    parent::__construct($translator);

    $this->metatagManager = \Drupal::service('metatag.manager');
  }

the $translator is what causes the issue. I think this was just copy pasted somehow from one of the core console commands?

When I have tried to add @translator as an argument to the service I get an error saying that no such service exists.

What fixed the issue for me was to remove the

tags:
      - { name: console.command }

part for the service definition in metatag.services.yml.

I have checked my Drupal codebase and this is actually the only place I can find this is added... Is that required?

I've overseen the contructor override in GenerateTagCommand. It depends on, what class/service the $translator variable should be.. Damien surely knows better... (Only because the class variable is named $translator, that does not imply that there's a service called "translator" - and even if it was, there's no guarantuee, that it's the right one). Like mentioned above, it must be of type Symfony\Component\Console\Helper\HelperSet according to the constructor of the base class. And also the GenerateGroupCommand needs this, even if it is not overriding the constructor at all.

The "tags" used in service.yaml files are used by plugin managers, etc in order to collect all registered services of a specific type. So if you remove it and it works, then I guess, it will just not get picked up by a specific plugin manager of Drupal Console.. I guess it has a similar effect as just remove the whole service declaration (solving the Drush issue, but maybe causing problems with the Console commands)

If you do not need the Drupal Console commands of Metatag at all, you could also just remove the concerning service declarations causing the error. See https://www.drupal.org/node/2788449#comment-11540385 for a patch

Allright. So I have backtraced the thing and it turns out it breaks on line 264 of Drupal\Component\DependencyInjection\Container.php
which is:

    protected function createService(array $definition, $id) {
      ...
      switch ($length) {
        case 0:
          // This is the line that faults
          $service = new $class();
          break;

        case 1:
          $service = new $class($arguments[0]);
          break;
...
...

$length is the number of arguments given to the service constructor and in this case it`s 0.
$class = Drupal\metatag\Command\GenerateGroupCommand

now this makes perfect sense that it breaks because the class constructor expects an argument whereas it is called $service = new $class(); - without them.

So there are few questions:
1. What should the $translator be? If we knew that we could inject that in a service definition:

  metatag_generate_tag:
    class: Drupal\metatag\Command\GenerateTagCommand
    arguments: ['@required.service']
    tags:
      - { name: console.command }

2. How do we deal with

    public function __construct(HelperSet $helperSet)
    {
        $this->setHelperSet($helperSet);
        parent::__construct();
    }

of Drupal\Console\Command afterwards??

GenerateTagCommand calls parent::__construct($translator); in its own construct...

I can live without the generate commands but I totally rely on composer on downloading both modules and patches. I already have patched the metatag module (for views integration) so the patch that you linked does not apply :). I can keep rerolling the patches or... figure out how to fix the issue :).

@tom_ek:

I already have patched the metatag module (for views integration) so the patch that you linked does not apply

As you can define more than one patch in your composoer.json and my patch is quite simple (only uncommenting lines from the services.yml), there can only be two reasons for that:

1. both patches manipulate the same file and intercept each other - well, then you really would have to patch it by yourself by adding the other stuff (or you could try changing the order of the patches first. this might help in some cases, if the same file is changed, but not on the same area)
2. they do not intercept each other at all. There's no obvious reason, why the second one does not apply at all and if you apply the patches by hand, both will apply successfully => well, then you're victim of a known bug of cweagans/composer-patches (https://github.com/cweagans/composer-patches/issues/42). This happens all the time, when I run composer update on projects having more than one patch. You simply have to run the same command a second time again, then it should work

Any reason to make this hard dependency?
This does not allow to use the module without console

imho it becomes apparent that Console's approach to discover services is not the best way, as this will always lead to an implicit dependency on Drupal Console, which is bad. Maybe an annotation based plugin discovery could help?

To stop the bleeding: apply #2788449-12: Fatal error after updating to 8.1.0-beta10. Conveniently uploaded here so you don't have to hunt for it.

@heddn Thanx for hotfix, I'm using the same to prevent failures
I think we need to commit this one as open follow-up to discus proper integration with console/drush

Any update on this.
I am getting same error when running drush config-export.
I have just update drush and console versions both.
current versions
drush 8.1.3
console 1.0.0-beta5

#13 works fine.

Told you so. #2391219: Stop the console project: doubles the contrib workload (and breaks it as well)

Same issue here. #13 did the trick.

don't want to be nitpicky.. but the committed code was originally my patch ;) but don't worry, no prob

No problem, thank you very much for clarification - wouldn't have been necessary at all, but thanks! :-)

Hopefully we wont need any patches anymore. I love to use both my console and drush. Worked like a charm

++ to this

attached is this applied against the latest beta10 if anyone needs it.

This will not apply against HEAD. See comment #25

Edit: Please ignore, was trying to do too many things at once.

The committed patch from #13 should apply to beta10 for the proper workaround.

I am still getting the error with beta10 with the patch on some drush commands. @brantwynn do you get the error when running drush uli?

Have not had any drush issues after applying #13 to beta10. #29 was a mistake patch and should not be used for the workaround.

Thanks! #13 did work for me as well.

#13 worked for me as well, following method:

cd modules/metatag/
wget https://www.drupal.org/files/issues/metatag-deactivate_drupalconsole_services_0.patch
patch < metatag-deactivate_drupalconsole_services_0.patch

#13 working here as well. Thanks!

#13 working fine. Thanks so much!

If you are using composer you can apply the patch by putting the following into the "extra" section of your composer.json.

    "prefer-stable": true,
    "extra": {
        "patches": {
            "drupal/metatag": {
                "Deactivate console service": "https://www.drupal.org/files/issues/metatag-deactivate_drupalconsole_services_0.patch"
            }
        },
        "installer-paths": {
            "config/shared": [
                "type:drupal-module-config"
            ],
            "web/core": [
                "type:drupal-core"
            ],
            "web/modules/contrib/{$name}": [
                "type:drupal-module"
            ],
            "web/modules/custom/{$name}": [
                "type:drupal-module-custom"
            ],
        }
    }

I think proper fix is to write service provider that adds this services only when console classes available

Hi folks

I just did a refactor of Metatag commands to be compatible with Drupal Console refactoring introduced at releases RC1+

The string languages are OK, but the DrupalConsole Core it's working in a splitting logic to enable language separation from Core, this change will be included in next two weeks for RC3 or RC4.

FYI the installer of Drupal Console is not the global application anymore, now the installer is just a launcher to locate and execute the Drupal Console located in your vendor folder, with this change you will be able to have different versions of Drupal and Drupal Console among your sites to avoid any conflict with dependencies between Drupal releases.

After install the latest version of Drupal (now launcher) you must install the Drupal Console with composer, as you can see below

# Getting Drupal Console Launcher
$ curl https://drupalconsole.com/installer -L -o drupal.phar
$ mv drupal.phar /usr/local/bin/drupal
$ chmod +x /usr/local/bin/drupal

# Installing Drupal Console with Composer
$ composer require drupal/console:~1.0 --prefer-dist --optimize-autoloader

+++ b/src/Command/GenerateGroupCommand.php
@@ -9,13 +9,15 @@ namespace Drupal\metatag\Command;
+use Drupal\Console\Command\Shared\CommandTrait;

so how this globally defined service can be registered in container if I have no console installed?

Hi @andypost

Those classes are only loaded by DrupalConsolel IF Drupal Console is installed.

You could check the metatag.service.Yml file and you could check the tags drupal.command and drupal.generator, those tags allow to separate services from Drupal services. So they are in the Drupal Container but are not used by any part of Drupal or Drush.

When you got Drupal Console installed, those classes and services are loaded and could be used as services in Drupal code Core or Custom if are required.

I tested with Drupal 8.2x. and 8.3.x without Drupal Console to confirm there is not conflict at all

Kind regards

Tested on my local and works! I'm also applying this patch to all my projects :)

Thank you :)

Testing.

Rewarded :)

Hmm how are you guys getting patch #40 to work? I tried with metatag beta 10 and beta 9, but patch failed to apply for me.

@dan2k3k4 you have to apply it to the dev branch. Patches don't always apply to full releases. Sometimes they do, but in this case, it doesn't.

But, since this has been committed to the dev branch, you might as well just use the dev branch at this point.

Isn't the real issue here that metatag relies on classes which should only ever be require-dev? I think moving them from services.yml to a ServiceProvider would make more sense.

@larowlan This is exactly what I said in #39 but we still have services that depends on non-existing classes (when console not installed)

So better to file follow-up and fix that properly

Using beta11 and installing composer as project dependency gives a new error:

PHP Fatal error: Cannot use Symfony\Component\Console\Command\Command as Command because the name is already in use in vendor/drupal/console-core/src/Command/CompleteCommand.php on line 12

So is the version of DrupalConsole on GitHub the latest, with all the necessary patches, etc?

There may well be other issues in the queue that are related, however, my particular issue is directly related to the initial message in this thread. I have another issue, which I was told would be resolved by running the command "drush entity-updates". However, when I do, I get the error

"Error: Class 'Drupal\Console\Command\GeneratorCommand' not found in {PATH}/modules/metatag/src/Command/GenerateGroupCommand.php, line 27"

Upon reporting this, I was told:

"The drush error seems to be coming from Drupal console and it has been fixed.

https://www.drupal.org/node/2786795"

I did a fresh install of DrupalConsole from Github, and attempted the Drush command again, and once again, I got the exact same error message.

Indeed I have the same issue. Installing the latest version of metatag and Drupal console doesn't fix metatag generator commands.
The discussion can be that Drupal console isn't ready to handle the metatag commands but then metatag should not include the commands in their beta release.

I am getting the same issue as above.