New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-discover non-Drupal commands #4696
Conversation
We may want to deprecate global commands discoverable via config (?) |
LGTM. @greg-1-anderson would be right person to review and merge this. |
We should make sure that Generators can be discovered similarly, and edit docs at https://www.drush.org/latest/generators/ accordingly. #4547 might be related. |
@weitzman I see global generators are already discovered by their namespace ( What about deprecating the old way for commands (see my previous comment) and generators ( |
Yes, I think so.
Yes, IMO. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is spot on; thank you for submitting it.
I am 👍 on merging this, but holding off for a bit to see if we want to add deprecations first. Auto-discovering generators would be good for consistency, but could be follow-on work IMO.
Generators are postponed to a followup. This is not a straight task as Consider to postpone also deprecations. In PR I'm suggesting to deprecate |
src/Application.php
Outdated
if ($commandsFromConfig) { | ||
@trigger_error("Discovering global commands by specifying them in 'drush.commands' config is deprecated and will be removed in Drush 11.0.0. See docs/commands.md on how to create auto-discoverable global commands.", E_USER_DEPRECATED); | ||
} | ||
$commandClasses = array_merge( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other question about this PR is, what happens if the same commandfile is found twice by multiple methods? For example, the example-drush-extension project creates an autoloadable class that is discovered based on its location, and is probably also discovered by this PR. I am presuming that this array_merge will cause these two identical items to become a single entry in the resulting array, since they should have the same key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, not all parts of the merge have keys. So, we should remove the keys > merge > array_unique(), assuming that there are no same two namespaces with different paths in this universe. That would be a nonsense and a bug somewhere.
src/Application.php
Outdated
@@ -320,8 +320,12 @@ public function configureAndRegisterCommands(InputInterface $input, OutputInterf | |||
$discovery = $this->commandDiscovery(); | |||
$commandClasses = $discovery->discover($commandfileSearchpath, '\Drush'); | |||
$commandClasses[] = \Consolidation\Filter\Hooks\FilterHooks::class; | |||
$commandsFromConfig = $this->commandsFromConfiguration(); | |||
if ($commandsFromConfig) { | |||
@trigger_error("Discovering global commands by specifying them in 'drush.commands' config is deprecated and will be removed in Drush 11.0.0. See docs/commands.md on how to create auto-discoverable global commands.", E_USER_DEPRECATED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if trigger_error
is too noisy. Maybe we should deprecate with trigger_error
in Drush 11, and remove in Drush 12? I know that's a long long ways off, but folks are very slow at upgrading Drush commands in modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that's a long long ways off, but folks are very slow at upgrading Drush commands in modules.
This is something that leads to exactly the opposite conclusion: If they're slow to adopt changes, then we should deprecate as soon as possible, giving them enough time to take action. We can change the removal version from 11.0.0 to 12.0.0 but the deprecation should occur now. Deprecating doesn't mean the command doesn't work. Also note that this is a muted deprecation @trigger_error(...)
, so there should be no noise in console. Normally code deprecation tests should catch this error but that's fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, deprecation is postponed.
My last comment is that maybe we should note in the documentation that this new loading mechanism is experimental, and subject to change until Drush 10.5 or 11.0 is tagged. |
I realize that it's early for this PR to deprecate the I think this PR is still good to merge; we can add DI as follow-on work. We should back out the deprecation, though. We could potentially deprecate auto-discovery by location ( |
Not sure it provides DI but, yes, let's drop the deprecation for now, it needs more analysis. |
4212b4f
to
e84b128
Compare
I guess I'm not that opposed to AutoloaderAwareTrait. |
Many thanks I confirm this satisfies my requirement mentioned in #4641 |
True, there is a way to discover such commands by adding their paths in Drush configuration. But I want to be able to have such commands available automatically, when I
composer require
a 3rd party library Drush commands provider.This PR uses the Robo
RelativeNamespaceDiscovery
to grab the Drush commands living in 3rd party libraries, loadable via PSR4. Such a class should comply with the following requirements:*\Drush\Commands
, e.g.My\Custom\Library\Drush\Commands
.*DrushCommands
, e.g.FooDrushCommands
.