-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Deprecate global configuration commands #5128
Conversation
3fd5c17
to
3fcd069
Compare
src/Application.php
Outdated
@@ -340,6 +343,13 @@ protected function discoverCommandsFromConfiguration() | |||
$commandList[$value] = $classname; | |||
} | |||
} | |||
|
|||
if ($commandList) { | |||
$message = dt('Discovering commands by configuration is deprecated in Drush 11.0.9 and is scheduled for removal in a future major version. The following command classes should be converted to PSR4 discovery (see docs/commands.md): !classes', ['!classes' => implode(', ', $commandList)]); |
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 would give a full URL to the docs. A relative path is not giving the user much info, as our code is buried in vendor.
The last commit was suggested by the Personal note from this blog post https://mglaman.dev/blog/auto-discovery-global-commands-drush
|
docs/commands.md
Outdated
} | ||
``` | ||
then the Drush global commands class namespace should be `My\Custom\Library\Drush\Commands` and the class file should be located under the `src/Drush/Commands` directory. | ||
* The class and file name ends with `*DrushCommands`, e.g. `FooDrushCommands`. |
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.
Should this be just *Commands now?
docs/commands.md
Outdated
then the Drush global commands class namespace should be `My\Custom\Library\Drush\Commands` and the class file should be located under the `src/Drush/Commands` directory. | ||
* The class and file name ends with `*DrushCommands`, e.g. `FooDrushCommands`. | ||
|
||
Unlike commands defined in Drupal modules, global commands don't benefit from dependency injection. However, it's still possible to interact with Drupal container services by using the `\Drupal::services()` static method. This can be achieved by defining the bootstrap level in the command attributes (see https://www.drush.org/latest/bootstrap) for details. A global command needing access to Drupal services should use the `DrupalBootLevels::FULL` bootstrap level. |
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 method is service(), not services() (not plural)
- Since 'bootstrap' is a link from one .md file to another .md file, you should use a relative path instead of an url.
Do we need to remove this completely? Pantheon still relies on global commandfiles to run the site audit tool on a bootstrapped Drupal site. This is safe for commandfiles that do not have dependencies of their own. Can we merely deprecated supporting dependencies in global commandfiles? We can't stop folks from loading their own autoload.php file, but we can tell them not to do it. |
I'd like to deprecate those commands. I think that sends the right signal that they are going away, and we avoid the autoloader foot gun. As for when we actually remove support, thats a flexible thing. It doesnt have to be Drush 12 (which has no release timeline yet anyway). |
The discovery we try to deprecate here is the one where command classes are listed in this way, in
This I found by reading the code because the documentation seems wrong. See https://github.com/drush-ops/drush/blob/11.x/docs/commands.md#commands-discovered-by-configuration These commands don't bootstrap Drupal either. Drush is only doing the autoload job by knowing their namspace and file path from There is a 3rd kind of commands: Site-Wide Drush Commands which I don't understand exactly if they are bootstraping Drupal. Note that we don't touch this kind of discovery in this PR. @greg-1-anderson So, what kind of discovery is Pantheon using: is it Site-Wide Commands (which in a Drupal project are typically under EDIT: Because on a long run I think we should also deprecate the Site-Wide Commands and stick with auto-discovery |
In fact I see no reason why we wouldn't deprecate also Site-Wide Commands discovery. Right now we have 3 ways of adding non-module commands and this looks very confusing. PSR4 auto-discovery is a better way. I see no reason why a project could not provide auto-loading. But maybe I'm missing something... |
The Pantheon platform has a number of features that interact with the Drupal site being managed. In order to run code on the Database, Pantheon makes an The way these custom commands work is that the shell user that Pantheon uses w/ ssh has a $HOME directory, and in that home directory there is a Drush configuration file. This configuration command uses If Drush at some point removed this capability, then Pantheon could re-implement this functionality with As I mentioned before, Pantheon would prefer not to add code to the Drupal site itself. Doing this is unreliable, e.g. the customer might decide to remove or disable the code, unaware of the consequences. Perhaps when we deprecate and update the documentation, we could stipulate that global command discovery is only intended for use by service providers. |
I have no objection to removing site-wide command discovery in Drush 12 in favor of autodiscovery. |
Deprecating site-wide discovery sounds good to me, if we are confident in the performance if RelativeNamespaceDiscovery. It traverses a directory for every namespace, so I pause to ask. On Mass.gov thats 174 namespaces. |
RelativeNamespaceDiscovery just traverses the list of namespaces, and does just one |
Not sure that getting rid of Site-Wide Commands discovery is worth the hassle for site owners because site aliases currently discover in these locations also and they cant migrate to PSR4 auto-discovery since they are yml files. For example both aliases and commands are found at https://github.com/massgov/openmass/tree/develop/drush. |
Site-wide commands share their autoloader with Drupal, so leaving them is safe. We could maybe reduce the directory iteration depth in Drush 12 if it's too deep, and gets off in the weeds in some sites. Didn't check what it's at now. |
No description provided.