Drush 14 Planning

[weitzman]

Rough thoughts around Drush 14. Your thoughts are welcome.

1. Remove backward compat for commands (e.g. drush.services.yml). They must use the new DI, PHP Attributes, etc.
2. Incorporate any ideas from Dex. The main attraction is removal of some or all of of consolidation/annotated_command. We would need replacements for:
   a) Hooks. See the 3rd approach at (i.e. Event Subscriber Way) at https://tomasvotruba.com/blog/2018/09/03/4-ways-to-add-global-option-or-argument-to-symfony-console-application and see https://medium.com/@fernando_28520/extend-your-symfony-console-app-with-events-and-attributes-ca8ec6321430
   b) Hands off to output formatting
   c) Other stuff

Since many folks will already be updating their commandfiles from prior releases, we might as well make other major changes now.

[greg-1-anderson]

I wouldn't mind seeing annotated_command retired. I don't know off the top of my head if there's anything it does that Symfony can't do (e.g. can Symfony hook everything we need to hook?).

Removing backwards compat also sounds like a good idea.

[claudiu-cristea]

Make command discovery alterable. I would like to be able to add commands not by annotated commands

[claudiu-cristea]

To be more specific: I would like write a command factory that reads a YAML file and creates Drush commands. We are using now https://github.com/openeuropa/task-runner to do that. But I don't like to have so may PHP runners on a project. I would like to limit to Drush

[Chi-teck]

I'd like Drush commands to be plain Symfony console commands.

[weitzman]

As you know, we already support plain Symfony Console commands. The core Drush commands wont likely become those because they are woefully inadequate compared to Drush commands. For example, they dont support output formatters.. Also, it is hard for a listener to hook an option, or validator, or interactor to a command, for example. Our ecosystem relies has always relied on hooks/listeners pretty heavily.

[weitzman]

I made a tiny console app which explored a lot off the ideas mentioned here. Feedback welcome https://github.com/weitzman/console-example

I'd like Drush commands to be plain Symfony console commands.

Thats the approach I took - for now.

[Chi-teck]

I also think that output formatters must be implemented as helpers and optionally added to a command via DI or trait without any magic. The currently taken approach makes it hard to set proper exit code in Drush commands.

[greg-1-anderson]

The general idea of the OutputFormatter design is that, for information-gathering commands, if you have a table of data that you'd like to output, then presumably the status code should be 0, and if the situation arises where the status code should not be 0, you should throw an exception and not output a table of data.

Note that OutputFormatters has always supported the use case of plain Symfony Console commands; see the API Usage section of the documentation. If you use the API directly like this, then you configure your output format options with code instead of annotations, and you may both output a table of data and return a non-zero exit status code.

[Chi-teck]

Sometimes you need a command to perform both actions.

1. Output some content
2. Return non-zero code if something went wrong
   For instances, composer check-platform-req works this way.